[编辑：] 早些时候，我问这个问题可能是一个框架不完善的问题，即何时使用 OOP 与何时使用过程编程 - 一些回复暗示我是在寻求帮助理解 OOP。 相反，我经常使用 OOP，但想知道何时使用过程方法。 从反馈来看，我认为存在相当强烈的共识，即 OOP 通常是一种更好的全面方法，但如果 OOP 架构从长远来看无法提供任何重用优势，则应该使用过程语言。
然而，我作为 Java 程序员的经历却并非如此。 我看到一个由 Perl 大师用我编写的代码的 1/10 重写的大型 Java 程序，看起来和我的 OOP 完美模型一样健壮。 我的架构得到了大量的重用，而且更简洁的程序方法产生了卓越的解决方案。
因此，冒着重复自己的风险，我想知道在什么情况下我应该选择过程而不是面向对象的方法。 您将如何提前识别 OOP 架构可能过度杀伤力以及过程方法更简洁和高效的情况。
谁能举例说明这些场景会是什么样子？
提前确定可以通过过程编程方法更好地服务的项目的好方法是什么？
[Edit:] Earlier I asked this as a perhaps poorly-framed question about when to use OOP versus when to use procedural programming - some responses implied I was asking for help understanding OOP. On the contrary, I have used OOP a lot but want to know when to use a procedural approach. Judging by the responses, I take it that there is a fairly strong consensus that OOP is usually a better all-round approach but that a procedural language should be used if the OOP architecture will not provide any reuse benefits in the long term.
However my experience as a Java programmer has been otherwise. I saw a massive Java program that I architected rewritten by a Perl guru in 1/10 of the code that I had written and seemingly just as robust as my model of OOP perfection. My architecture saw a significant amount of reuse and yet a more concise procedural approach had produced a superior solution.
So, at the risk of repeating myself, I'm wondering in what situations should I choose a procedural over an object-oriented approach. How would you identify in advance a situation in which an OOP architecture is likely to be overkill and a procedural approach more concise and efficient.
Can anyone suggest examples of what those scenarios would look like?
What is a good way to identify in advance a project that would be better served by a procedural programming approach?
发布评论
评论（23）
在重用方面，我喜欢 Glass 规则 3（这似乎是你感兴趣的是什么）。
由此我认为你可以推断出这些推论
我仍然认为 OOP 对于构建一次性组件很有用，因为您始终可以将其重构为以后真正可重用的东西。 （您也可以从 PP 重构为 OOP，但我认为 OOP 在组织和封装方面具有足够的优势，可以从这里开始）
I like Glass' rules of 3 when it comes to Reuse (which seems to be what you're interested in).
From this I think you can extrapolate these corollaries
I still think OOP is useful for building the single use component, because you can always refactor it into something that is really reusable later on. (You can also refactor from PP to OOP but I think OOP comes with enough benefits regarding organization and encapsulation to start there)
那些虔诚地支持 OOP 的人没有任何事实来证明他们的支持是正确的，正如我们在这些评论中看到的那样。 他们在大学接受过训练（或洗脑），只会使用和赞扬 OOP，而且只是 OOP，这就是为什么他们如此盲目地支持 OOP。 他们在 PP 方面做过任何真正的工作吗？ 除了在团队环境中保护代码免受粗心程序员的侵害之外，OOP 并没有提供太多功能。 我个人在 PP 和 OOP 领域工作多年，发现 PP 简单、直接、高效，我同意以下智者的观点：（
参考：http://en.wikipedia.org/wiki/Object-oriented_programming)：
许多著名的研究人员和程序员都批评了 OOP。 以下是一个不完整的列表：
Luca Cardelli 写了一篇题为“面向对象语言的不良工程属性< /a>”。
Richard Stallman 在 1995 年写道：“向 Emacs 添加 OOP 显然并不是一种改进；而是一种改进。” 我在开发 Lisp Machine 窗口系统时使用了 OOP，但我不同意通常的观点，即它是一种更好的编程方式。”
Potok 等人的一项研究。 表明，OOP 和过程方法之间的生产力没有显着差异。
Christopher J. Date 指出，由于缺乏一致认可的 OOP 严格定义，将 OOP 与其他技术（尤其是关系技术）进行严格比较是很困难的。 提出了 OOP 的理论基础，即使用 OOP 作为一种可定制的类型系统来支持 RDBMS。
Alexander Stepanov 认为 OOP 提供了一种数学上有限的观点，并称其“几乎与人工智能一样是一场骗局”（可能指的是 20 世纪 80 年代的人工智能项目和营销，现在回想起来有时被认为过于热心）亚历山大
Paul Graham 认为 OOP 的目的是充当一种“羊群机制”，防止平庸组织中的平庸程序员“造成太大损害”。 这是以减慢那些知道如何使用更强大、更紧凑技术的程序员的生产力为代价的。
Erlang 的主要发明者 Joe Armstrong 曾说过：“面向对象语言的问题在于它们随身携带着所有这些隐式环境。 你想要一根香蕉，但你得到的是一只拿着香蕉的大猩猩和整个丛林。”
理查德·曼斯菲尔德 (Richard Mansfield)，COMPUTE! 的作者和前编辑！ 杂志指出，“就像多年来无数其他知识时尚一样（‘相关性’、共产主义、‘现代主义’等等——历史上充斥着它们），面向对象编程将与我们同在，直到现实最终证明自己。 但考虑到 OOP 目前在大学和工作场所的渗透程度，OOP 很可能被证明是一种持久的错觉。 整整几代受过灌输的程序员继续走出学院，在他们的余生中致力于 OOP，除了 OOP。” 也有人引用这样的话：“OOP 之于编写程序，就像通过机场安检之于飞行一样。”
Those who religiously support OOP don't have any facts to justify their support, as we see here in these comments as well. They are trained (or brain washed) in universities to use and praise OOP and OOP only and that is why they support it so blindly. Have they done any real work in PP at all? Other then protecting code from careless programmers in a team environment, OOP doesn't offer much. Personally working both in PP and OOP for years, I find that PP is simple, straight forward and more efficient, and I agree with the following wise men and women:
(Reference: http://en.wikipedia.org/wiki/Object-oriented_programming):
A number of well-known researchers and programmers have criticized OOP. Here is an incomplete list:
Luca Cardelli wrote a paper titled “Bad Engineering Properties of Object-Oriented Languages”.
Richard Stallman wrote in 1995, “Adding OOP to Emacs is not clearly an improvement; I used OOP when working on the Lisp Machine window systems, and I disagree with the usual view that it is a superior way to program.”
A study by Potok et al. has shown no significant difference in productivity between OOP and procedural approaches.
Christopher J. Date stated that critical comparison of OOP to other technologies, relational in particular, is difficult because of lack of an agreed-upon and rigorous definition of OOP. A theoretical foundation on OOP is proposed which uses OOP as a kind of customizable type system to support RDBMS.
Alexander Stepanov suggested that OOP provides a mathematically-limited viewpoint and called it “almost as much of a hoax as Artificial Intelligence” (possibly referring to the Artificial Intelligence projects and marketing of the 1980s that are sometimes viewed as overzealous in retrospect).
Paul Graham has suggested that the purpose of OOP is to act as a “herding mechanism” which keeps mediocre programmers in mediocre organizations from “doing too much damage”. This is at the expense of slowing down productive programmers who know how to use more powerful and more compact techniques.
Joe Armstrong, the principal inventor of Erlang, is quoted as saying “The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.”
Richard Mansfield, author and former editor of COMPUTE! magazine, states that “like countless other intellectual fads over the years (“relevance”, communism, “modernism”, and so on—history is littered with them), OOP will be with us until eventually reality asserts itself. But considering how OOP currently pervades both universities and workplaces, OOP may well prove to be a durable delusion. Entire generations of indoctrinated programmers continue to march out of the academy, committed to OOP and nothing but OOP for the rest of their lives.” and also is quoted as saying “OOP is to writing a program, what going through airport security is to flying”.
可重用性（或缺乏可重用性）并不局限于任何特定的编程范例。 根据需要使用面向对象、过程、函数或任何其他编程。 组织和可重用性来自您所做的事情，而不是来自工具。
Reusability (or lack of it) is not bound to any specific programming paradigm. Use object oriented, procedural, functional or any other programming as needed. Organization and reusability come from what you do, not from the tool.
您自己给出了答案 - 大项目只需要 OOP 来防止变得太混乱。
在我看来，OOP最大的优点是代码组织。 这包括DRY和封装的原则。
You gave the answer yourself - big projects simply need OOP to prevent getting too messy.
From my point of view, the biggest advantage of OOP is code organization. This includes the principles of DRY and encapsulation.
我建议使用针对任何给定问题都能找到的最简洁、基于标准的方法。 您使用 Perl 的同事证明，无论采用何种方法，熟悉特定工具的优秀开发人员都可以取得出色的成果。 我不想将 Java 与 Perl 项目作为过程与 OOP 辩论的一个很好的例子，而是希望看到 Perl 与类似简洁的语言（例如 Ruby）之间的对峙，而 Ruby 恰好也有优点面向对象。 现在这是我想看到的。 我的猜测是 Ruby 会名列前茅，但我对在这里引发一场语言之战不感兴趣 - 我的观点只是你为工作选择合适的工具 - 无论哪种方法都可以最有效和最稳健地完成任务方式可能。 Java 可能因其面向对象而很强大，但正如您和您的同事以及许多其他正在转换为动态语言（例如 Ruby 和 Python）的人现在所发现的那样，有更有效的解决方案，无论是过程式还是 OOP。
I would suggest using the most concise, standards-based approach that you can find for any given problem. Your colleague who used Perl demonstrated that a good developer who knows a particular tool well can achieve great results regardless of the methodology. Rather than compare your Java-versus-Perl projects as a good example of the procedural-versus-OOP debate, I would like to see a face-off between Perl and a similarly concise language such as Ruby, which happens to also have the benefits of object orientation. Now that's something I'd like to see. My guess is Ruby would come out on top but I'm not interested in provoking a language flame-war here - my point is only that you choose the appropriate tool for the job - whatever approach can accomplish the task in the most efficient and robust way possible. Java may be robust because of its object orientation but as you and your colleague and many others who are converting to dynamic languages such as Ruby and Python are finding these days, there are much more efficient solutions out there, whether procedural or OOP.
我认为 DRY 原则（不要重复自己）与一点敏捷相结合是一个很好的方法。 从最简单的可行方法开始逐步构建您的程序，然后一一添加功能，并根据需要重构您的代码。
如果您发现自己一次又一次地编写相同的几行代码（可能使用不同的数据），那么是时候考虑抽象了，它可以帮助将变化的内容与保持不变的内容分开。
为每次迭代创建彻底的单元测试，以便您可以充满信心地进行重构。
花费太多时间试图预测代码的哪些部分需要可重用是错误的。 一旦系统规模开始扩大，这一点很快就会变得明显。
对于具有多个并发开发团队的大型项目，您需要有某种架构计划来指导开发，但如果您是自己工作或在小型合作团队中工作，那么如果您坚持 DRY 原则，架构就会自然出现。
这种方法的另一个优点是，无论你做什么都是基于现实世界的经验。 我最喜欢的比喻是——在想象如何建造建筑物之前，你必须先玩弄砖块。
I think DRY principle (Don't Repeat Yourself) combined with a little Agile is a good approach. Build your program incrementally starting with the simplest thing that works then add features one by one and re-factor your code as necessary as you go along.
If you find yourself writing the same few lines of code again and again - maybe with different data - it's time to think about abstractions that can help separate the stuff that changes from the stuff that stays the same.
Create thorough unit tests for each iteration so that you can re-factor with confidence.
It's a mistake to spend too much time trying to anticipate which parts of your code need to be reusable. It will soon become apparent once the system starts to grow in size.
For larger projects with multiple concurrent development teams you need to have some kind of architectural plan to guide the development, but if you are working on your own or in small cooperative team then the architecture will emerge naturally if you stick to the DRY principle.
Another advantage of this approach is that whatever you do is based on real world experience. My favourite analogy - you have to play with the bricks before you can imagine how the building might be constructed.
我认为当您有非常明确的问题，规范不会改变并且您想要非常快运行时，您应该使用过程式风格为它编写程序。 在这种情况下，您可以用可维护性来换取性能。
当您编写游戏引擎或科学模拟程序时，通常会出现这种情况。 如果您的程序每秒计算超过一百万次，则应该针对边缘进行优化。
您可以使用非常有效的算法，但在优化缓存使用之前，它的速度不够快。 缓存数据可以大大提高性能。 这意味着 CPU 不需要从 RAM 中获取字节，它知道它们。 为了实现这一点，您应该尝试将数据彼此靠近存储，可执行文件和数据大小应该最小，并尝试使用尽可能少的指针（在您负担得起的情况下使用静态全局固定大小的数组）。
如果您使用指针，您会在内存中不断跳转，并且 CPU 每次都需要重新加载缓存。 OOP 代码充满了指针：每个对象都通过其内存地址存储。 你在任何地方调用 new ，这会将你的对象分布在整个内存中，使得缓存优化几乎不可能（除非你有一个分配器或垃圾收集器来使对象彼此靠近）。 您调用回调和虚函数。 编译器通常无法内联虚函数，并且虚函数调用相对较慢（跳转到VMT，获取虚函数的地址，调用它[这涉及将参数和局部变量压入堆栈，执行函数然后弹出所有内容]）。 当每秒从 0 到 1000000 运行 25 次的循环时，这一点非常重要。 通过使用过程风格，没有虚函数，并且优化器可以内联这些热循环中的所有内容。
I think you should use procedural style when you have a very well specified problem, the specification won't change and you want a very fast running program for it. In this case you may trade the maintainability for performance.
Usually this is the case when you write a game engine or a scientific simulation program. If your program calculate something more than million times per second it should be optimized to the edge.
You can use very efficient algorithms but it won't be fast enough until you optimize the cache usage. It can be a big performance boost your data is cached. This means the CPU don't need fetch bytes from the RAM, it know them. To achieve this you should try to store your data close to each other, your executable and data size should be minimal, and try using as less pointers as you can (use static global fixed sized arrays where you can afford).
If you use pointers you are continuously jumping in the memory and your CPU need to reload the cache every time. OOP code is full of pointers: every object is stored by its memory address. You call
neweverywhere which spread your objects all over the memory making the cache optimization almost impossible (unless you have an allocator or a garbage collector that keeps things close to each other). You call callbacks and virtual functions. The compiler usually can't inline the virtual functions and a virtual function call is relatively slow (jump to the VMT, get the address of the virtual function, call it [this involves pushing the parameters and local variables on the stack, executing the function then popping everything]). This matters a lot when you have a loop running from 0 to 1000000 25 times in every second. By using procedural style there aren't virtual function and the optimizar can inline everything in those hot loops.我认为 OOP 的适用性更多地取决于您所从事的主题领域，而不是项目的规模。 在某些主题领域（CAD、仿真建模等），OOP 自然地映射到所涉及的概念。 然而，还有许多其他领域的映射最终变得笨拙且不协调。 许多人在所有事情上都使用面向对象编程，似乎花了很多时间试图将方钉敲入圆孔。
OOP 有它的一席之地，但过程式编程、函数式编程等也有它的一席之地。看看您要解决的问题，然后选择一种编程范例，使您能够编写最简单的程序来解决它。
I think the suitability of OOP depends more on the subject area you're working in than the size of the project. There are some subject areas (CAD, simulation modeling, etc.) where OOP maps naturally to the concepts involved. However, there are a lot of other domains where the mapping ends up being clumsy and incongruous. Many people using OOP for everything seem to spend a lot of time trying to pound square pegs into round holes.
OOP has it's place, but so do procedural programming, functional programming, etc. Look at the problem you're trying to solve, then choose a programming paradigm that allows you to write the simplest possible program to solve it.
如果项目很小，以至于它包含在一个类中并且不会使用很长时间，我会考虑使用函数。 或者，如果您使用的语言不支持 OO（例如 c）。
If the project is so small that it would be contained within one class and is not going to be used for very long, I would consider using functions. Alternatively if the language you are using does not support OO (e.g. c).
你想要丛林吗？
Do you want the jungle?
对于某种类型的程序，过程式程序可以更简单。 通常，这些是类似脚本的简短程序。
Procedural programs can be simpler for a certain type of program. Typically, these are the short script-like programs.
考虑这种情况：
你的代码不是OO。 您的程序中具有数据结构和许多对数据结构进行操作的函数。 每个函数都采用数据结构作为参数，并根据数据结构中的“data_type”字段执行不同的操作。
如果一切正常并且不会改变，谁在乎它是否是面向对象的呢？ 它正在发挥作用。 完成。 如果您可以通过程序更快地达到这一点，那么也许这就是要走的路。
但你确定不会改变吗？ 假设您可能添加新类型的数据结构。 每次添加您希望这些函数对其进行操作的新数据结构类型时，您都必须确保找到并修改每个函数以添加新的“else if”情况来检查并添加您想要的行为影响新的数据结构类型。 随着程序变得越来越大、越来越复杂，这种痛苦也会增加。 这种情况发生的可能性越大，采用面向对象方法的情况就越好。
并且 - 您确定它运行时没有错误吗？ 涉及的切换逻辑越多，每个代码单元的测试就越复杂。 通过多态方法调用，该语言可以为您处理切换逻辑，并且每个方法都可以更简单、更容易测试。
Consider this scenario:
Your code is not OO. You have data structures and many functions throughout your progam that operate on the data structures. Each function takes a data structure as a parameter and does different things depending on a "data_type" field in the data structure.
IF all is working and not going to be changed, who cares if it's OO or not? It's working. It's done. If you can get to that point faster writing procedurally, then maybe that's the way to go.
But are you sure it's not going to be changed? Let's say you're likely to add new types of data structures. Each time you add a new data structure type that you want those functions to operate on, you have to make sure you find and modify every one of those functions to add a new "else if" case to check for and add the behavior you want to affect the new type of data structure. The pain of this increases as the program gets larger and more complicated. The more likely this is, the better off you would be going with the OO approach.
And - are you sure that it's working with no bugs? More involved switching logic creates more complexity in testing each unit of code. With polymorphic method calls, the language handles the switching logic for you and each method can be simpler and more straightforward to test.
这两个概念并不相互排斥，你很可能将 PP 与 OOP 结合使用，我不知道如何将它们分开。
The two concepts are not mutually exclusive, it is very likely that you will use PP in conjunction with OOP, I can't see how to segregate them.
我相信 Grady Booch 曾经说过，在 10000 多行代码中，你真的开始从 OOP 中受益匪浅。
然而，我总是走面向对象的道路。 即使是 200 行。 从长远来看，这是一种更好的方法，而开销只是一个被高估的借口。 所有的大事都是从小事开始的。
I believe Grady Booch said once that you really start to benefit a lot from OOP at 10000+ lines of code.
However, I'd always go the OO-way. Even for 200 lines. It's a superior approach in a long term, and the overhead is just an overrated excuse. All the big things start small.
OOP 的目标之一是使可重用性更容易，但这不是唯一的目的。 学习有效使用对象的关键是设计模式。
我们都习惯了算法的思想，它告诉我们如何组合不同的过程和数据结构来执行常见的任务。 相反，请参阅四人帮的设计模式，了解如何组合对象来执行常见任务的想法。
在了解设计模式之前，我对如何有效地使用对象而不是作为超类型结构一无所知。
请记住，实现接口与继承一样重要，甚至更重要。 过去，C++ 是面向对象编程的领先示例，与继承（虚拟函数等）相比，使用接口是模糊的。 C++ 遗产意味着在各种教程和广泛概述中更加强调重用行为。 从那时起，Java、C# 和其他语言已经将界面变得更加受关注。
接口的伟大之处在于精确定义两个对象如何相互交互。 这与重用行为无关。 事实证明，我们的软件大部分都是关于不同部分如何交互的。 因此，使用接口比尝试制作可重用的组件可以提高更多的生产力。
请记住，像许多其他编程思想一样，对象是一种工具。 您必须使用您的最佳判断来判断它们对您的项目的效果如何。 对于我的金属切削机 CAD/CAM 软件，有一些重要的数学函数没有放置在对象中，因为它们没有理由放置在对象中。 相反，它们从库中公开并由需要它们的对象使用。 然后有一些数学函数是面向对象的，因为它们的结构自然导致了这种设置。 （获取点列表并将其转换为几种不同类型的切割路径）。 再次运用你的最佳判断。
One of the goals of OOP was to make reusability easier however it is not the only purpose. The key to learning to use objects effectively is Design Patterns.
We are all used to the idea of algorithms which tell us how to combine different procedures and data structures to perform common tasks. Conversely look at Design Patterns by the Gang of Four for ideas on how to combine objects to perform common tasks.
Before I learned about Design Patterns I was pretty much in the dark about how to use objects effectively other than as a super type structure.
Remember that implementing Interfaces is just as important if not more important than inheritance. Back in the day C++ was leading example of object oriented programming and using interfaces are obscured compared to inheritance (virtual functions, etc). The C++ Legacy meant a lot more emphasis was placed on reusing behavior in the various tutorials and broad overviews. Since then Java, C#, and other languages have moved interface up to more a focus.
What interfaces are great for is precisely defining how two object interact with each. It is not about reusing behavior. As it turns out much of our software is about how the different parts interact. So using interface gives a lot more productivity gain than trying to make reusable components.
Remember that like many other programming ideas Objects are a tool. You will have to use your best judgment as to how well they work for your project. For my CAD/CAM software for metal cutting machines there are important math functions that are not placed in objects because there is no reason for them be in objects. Instead they are exposed from library and used by the object that need them. Then there is are some math function that were made object oriented as their structure naturally lead to this setup. (Taking a list of points and transforming it in on of several different types of cutting paths). Again use your best judgment.
您的部分答案取决于您使用的语言。 我知道在 Python 中，将过程代码移动到类或更正式的对象中非常简单。
我的启发之一是基于情况的“状态”。 如果该过程污染了命名空间，或者可能影响全局状态（以不良或不可预测的方式），那么将该函数封装在对象或类中可能是明智的。
Part of your answer depends on what language you're using. I know that in Python, it's pretty simple to move procedural code into a class, or a more formal object.
One of my heuristics is a based on how the "state" of the situation is. If the procedure pollutes the namespace, or could possibly affect the global state (in a bad, or unpredictable way), then encapsulating that function in an object or class is probably wise.
我的两分钱...
过程式编程的优点
动态需求）
更少 程序代码越接近功能性，就越优秀。 FP的优点是众所周知的。
My two cents...
Advantages of procedural programming
dynamic requirements)
The more Procedural code become good the closer it's to Functional. And advantages of FP are well known.
我总是以自上而下的方式开始设计，在顶部部分，用 OOP 术语思考要容易得多。 但是，当需要编写一些特定的小部分时，仅通过过程编程即可提高工作效率。
OOP 在设计和塑造项目方面很酷，因此可以应用分而治之的范式。 但你不能将它应用到代码的每个方面，因为它是一种宗教:)
I always begin designing in a top-down fashion and in the top parts it's much easier to think in OOP terms. But when comes the time to code some little specific parts you are much more productive with just procedure programming.
OOP is cool in designing and in shaping the project, so that the divide-et-impera paradigm can be applied. But you cannot apply it in every aspect of your code, as it were a religion :)
如果您在编程时“思考面向对象”，那么我不确定问“我什么时候应该恢复到过程式编程？”是否有意义。 这相当于问java程序员什么不能做，因为java需要类。 （.NET 语言也是如此）。
如果你必须努力克服程序性思考，那么我建议你询问如何克服这个问题（如果你愿意的话）； 否则继续按程序进行。 如果进入 OOP 模式需要付出如此多的努力，那么您的 OOP 代码可能无论如何都不会很好地工作（除非您进一步沿着学习曲线前进。）
If you "think OO" when you're programming, then I'm not sure it makes sense to ask "when should I revert to procedural programming?" This is equivalent to asking java programmers what they can't do as well because java requires classes. (Ditto .NET languages).
If you have to make an effort to get past thinking procedurally, then I'd advise asking about how you can overcome that (if you care to); otherwise stay with procedural. If it's that much effort to get into OOP-mode, your OOP code probably won't work very well anyway (until you get further along the learning curve.)
恕我直言，OOP 的长期好处超过了短期节省的时间。
就像 AZ 所说，以过程方式使用 OOP（我经常这样做）是一个很好的方法（对于较小的项目）。 项目越大，您应该使用越多的 OOP。
IMHO, the long term benefits of OOP outweigh the time saved in the short term.
Like AZ said, using OOP in a procedural fashion (which I do quite a bit), is a good way to go (for smaller projects). The bigger the project, the more OOP you should employ.
在这两个概念中你都可能写出糟糕的软件。 尽管如此，复杂的软件用 OO 语言比用过程语言更容易编写、理解和维护。 我用过程语言 (Oracle PL/SQL) 编写了高度复杂的 ERP 应用程序，然后改用 OOP (C#)。 无论过去还是现在，这都是一股新鲜空气。
You can write bad software in both concepts. Still, complex software are much easier to write, understand and maintain in OO languages than in procedural. I wrote highly complex ERP applications in procedural language (Oracle PL/SQL) and then switched to OOP (C#). It was and still is a breath of fresh air.
到目前为止，使用 OO 进行 DRY 和封装的争论只是增加了不必要的复杂性，因为它的隐式程度以及一个类可以继承大量属性和方法的层数。
更不用说设计一个好的面向对象确实很难，因为您最终会添加不相关/不必要的东西，这些东西将在继承它们的类的整个层中继承。 如果一个父类变得混乱，那么整个代码库就会变得混乱，这真的很糟糕。 并被重构。
还有一个事实是，这些继承的属性并不特别适合继承它的类的用例，需要重写。 对于那些根本不需要它们的人来说，他们只是无缘无故地拥有它们。
对于不需要共享的东西，当然有抽象属性。 但您最终必须在尝试继承它们的所有实例中实现它们。
这个传承太神奇了，而且很危险。
但我认为 OO 擅长执行应该可用的内容。 但话又说回来，权力太大了，很容易被错误地使用。
在我看来，最后一堂课应该是默认的。 并且需要慎重选择是否允许其继承。
To this point, the arguments of using OO for DRY and encapsulation is just adding unnecessary complexity in terms of how implicit it is and just sheer of how many layers that a class can inherit a lot of properties and methods into it.
not to mention that it's really hard to design a good OO cause you'd end up adding unrelated/unnecessary things that are going to be inherited throughout the whole layers of classes that inherits them. which is really bad if one parent class gets messy, the whole codebase is messy. and gets refactored.
also the fact that those inherited properties are not specifically fit into the use case to the class that inherits it which requires to be overridden. and to the ones that don't need them at all just have them for no good reason.
for something that does not need to be shared, sure there's abstract properties. but you'd end up having to implement them in all the instances that tries to inherits them.
this inheritance is just too magicky and gets dangerous.
but I'd give OO credit on how it's good at enforcing of what should be available. but then again it's too much power that is really easy to be wrongly used.
In my opinion, final class should be the default. and you need to deliberately choose if you want to allow it to inheritance.
大多数研究发现，OO 代码比过程代码更简洁。 如果您查看用 C++ 重写现有 C 代码的项目（顺便说一句，我不一定建议这样做），您通常会看到代码大小减少了 50% 到 75%。
所以答案是——始终使用 OO！
Most studies have found that OO code is more concise than procedural code. If you look at projects that re-wrote existing C code in C++ (not something I necessarily advise, BTW) , you normally see reductions in code size of between 50 and 75 percent.
So the answer is - always use OO!