oop之面向对象编程中的设计模式是否标志着面向对象范式的系统性问题

这个问题在这里已经有了答案:




10年前关闭。

Possible Duplicate:
Are design patterns really language weaknesses?

在花了数年时间翻阅关于 OOP 和 OOP 技术的书籍，并且最近越来越多地参与编程的函数式风格之后，推断设计模式是指向整个面向对象编程的系统问题的指针是否公平？面向对象编程(不要与设计混淆)是否存在根本缺陷，在于通过封装处理状态，导致越来越多的模式来解决这种范式的问题。

我还没有就此得出任何结论，但我的“直觉”感觉是 OOP 的范式可能存在更严重的错误。

封装的想法是否会导致比它们解决的问题更多的问题。

请您参考如下方法:

一个很好的问题，也是我前段时间思考过的问题。这是我的结论\意见:

面向对象编程的思想并非没有缺陷，但确实提供了最完整的设计范式。如果问题域表达得当，明确定义的对象，知道他们的职责，可以以相当优雅的方式进行交互，这非常类似于对象在现实世界中的交互。 (或想法)。

为了把一些比较抽象的概念具体化，OOP 做了一些断言。 (就像封装一样，不要暴露超过你必须承担的责任和对象责任)。

像所有通用假设一样，也有异常(exception)，通常是一个好主意，但可能不适合手头的特定问题。 OOP 几乎涵盖了所有设想的问题(与 AOP 甚至更复杂的语义建模不同，它迎合特定类型的问题)这一事实也无济于事。

因此，在某些情况下，当您需要异常(exception)并远离 OOP 断言时，设计师需要一种方法来保持良好设计的界限，这样他们就不会偏离公认的设计实践太多。

所以设计模式，对我来说只是问题的案例研究，OOP 的一些核心断言不会提供这种服务。除了解决方案的协作和整理，设计模式还有助于增强 OOP。 (特别是对于新手设计师)。

注意:大多数时候，不需要设计模式。使用模式需要有明确的理由。我知道，一些新手，试图实现一些设计模式，只是因为他们了解它们(有时不是那么新手;))。它的方钉，圆孔问题