是否有可能成功地设计和构建基于程序（命令式）的应用程序？
您能否提供当今程序化且保持高水平完整性和效率的应用程序示例？ 是否有任何书籍、教程或链接提供了如何成功构建和维护命令式系统的示例？ 如果您要在该领域提供指导，您会就如何构建该领域提供哪些建议？ 我问这个问题是因为 OOP 通常被认为是过程编程的自然发展，但我很难相信情况总是如此。
Can you provide examples of applications today that are procedural and maintain a high level of integrity and efficiency? Are there any books, tutorials or links that provide examples of how to successfully build and maintain an imperative system? If you were to give guidance in this area, what tips would you give on how it should be structured? I ask because OOP is often presented as a natural progression of procedural programming, but I have trouble believing that is always the case.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
成功程序应用的例子？
你的意思是，比如说，Linux 内核？ BSD 内核？ Apache 网络服务器？ 大部分 Unix 用户态实用程序？ 类似的应用程序？
当然，OOP 技术在软件内的组织、可维护性和抽象方面具有价值，但即使在今天，OOP 也可能只是当今编写的所有代码和应用程序的少数子集。
考虑一下所有 Java 或 C# 或 VB 代码，虽然它们是用支持 OOP 的编程语言编写的，但它们使用大量 OOP 技术的唯一原因是与外部库或系统交互。 同时，应用程序本身在利用 OOP 框架的同时，在设计和实现方面可能相当程序化。
OOP 是一个很好的范例，但事实上，对于许多系统中的大部分逻辑来说，它并不是真正必要的。
Examples of successful procedural applications??
You mean like, say, the Linux kernel? BSD kernel? Apache web server? The vast bulk of the Unix userland utilities? Applications like that?
Of course OOP techniques have value in the organization, maintainability, and abstractions within software, but even today OOP is likely a minority subset of all the code and applications written today.
Consider all of the Java or C# or VB code that while written in a OOP capable programming language, the only reason they're using much OOP technique at all is to interact with external libraries or systems. Meanwhile the applications themselves, while leveraging OOP frameworks, are likely quite procedural in design and implementation.
OOP is a fine paradigm, but in truth it's not really necessary for the bulk of logic in many systems.
虽然我无法直接指出任何现有系统，但仍有大量在 OO COBOL 之前编写的遗留企业系统。 许多经典的 4GL 程序都是程序性的，旨在实现高度完整性的系统工程。 有些写得很好，有些则不太好。
书籍包括《COBOL从微型机到大型机》、《企业COBOL编程指南》。
良好的命令式代码的结构技巧类似于 OO 技术：良好命名、分离您的关注点、不要重复自己、单一责任原则、不要让破损的窗户得不到修补。
事实上，我只是建议阅读“实用程序员”会给大多数人在任何范例中提供正确的想法。
至于面向业务的应用程序转向 OO 的令人信服的理由； 过程语言允许使用事务脚本方法来处理域逻辑，而面向对象语言则允许域模型方法。
当然，对于简单的练习，没有真正需要使用 OO 语言，但是一旦复杂性增加，OO 语言的可维护性就胜过过程语言的低开销。
While I cant point toward any existing system directly, there are massive amounts of legacy enterprise systems written pre-OO COBOL. Many classic 4GL programs are procedural and are aimed at high integrity systems engineering. Some are well written, others not so much.
Books include "COBOL from Micro to Mainframes", "Enterprise COBOL Programming Guide."
Structural tips on good imperative code are similar to OO techniques: name things well, seperate your concerns, dont repeat yourself, single responsibility principle, dont leave broken windows unmended.
In fact I'd simply suggest reading the "Pragmatic Programmer" would give most people the right idea in any paradigm.
As far as a compelling reason for moving to OO for business oriented applications; procedural languages allow for a transaction script approach to domain logic, whereas OO languages allow for the domain model approach.
Certainly for simple exercises, there is no real need for the use of OO languages, but as soon as complexity rises, the maintainability of OO languages wins over procedural languages low overhead.