WeN*_*ers 7 oop design-patterns apache-fop
可能重复:
设计模式真的是语言缺陷吗？
在花了多年时间阅读有关OOP和OOP技术的书籍,并且最近越来越多地参与编程的功能样式之后,推断设计模式是指向面向对象编程作为一个整体的系统性问题的指针是否公平.面向对象编程是否存在根本性缺陷(不要与设计混淆),因为在通过封装处理状态时,已经导致越来越多的模式来解决这种范式的问题.
我对此没有得出任何结论,但我的"直觉"感觉是OOP范式可能会出现更严重的错误.
封装的想法是否导致了比他们解决的问题更多的问题.
一个非常好的问题和我前段时间想过的事情.这是我的结论\意见:
面向对象编程的想法并非没有缺陷,但确实提供了最完整的设计范例.如果问题域被正确表达,明确定义的对象(谁知道他们的职责)可以以相当优雅的方式进行交互,这非常类似于对象的真实世界交互.(或想法).
为了制作一些更抽象的概念,特定的,OOP会产生一些断言.(就像封装一样,不要暴露超过你必须和对象的责任).
像所有通用假设一样,当通常是一个好主意时,会有例外,可能不适合手头的特定问题.OOP涵盖了几乎所有构思的问题(不像AOP,甚至更复杂的语义建模,可以满足特定类型的问题),这也没有帮助.
所以在某些情况下,当你需要制作异常并摆脱OOP断言时,设计师需要一种方法来保持良好的设计,这样他们就不会过多地偏离公认的设计实践.
因此,对我而言,设计模式只是问题的案例研究,OOP的某些核心主张无法提供.除了解决方案的协作和整理,设计模式也有助于增加OOP.(特别是对于新手设计师).
注意:大多数情况下,不需要设计模式.需要明确使用模式的理由.我知道,一些绿色的,试图实现一些设计模式,只是因为他们知道它们(有时候不是那么的绿色角);).它的方形钉,圆孔问题
好问题，几周前我开始思考这个问题，同时更多地了解 Python 和 Scala。
我认为是和否。OOP 和状态封装肯定存在一些内在的问题，但这并不是说 OOP 本身本质上是一种不好的做事方式。我认为问题在于，当你只有一把锤子时，一切都变成了钉子。OOP 对于某些事情来说非常有用，首先想到的是 GUI，但函数式编程也有非常明显的好处。
值得注意的是，Scala 等较新的函数式编程语言并没有抛弃对象。
我没有详细考虑过这个问题，但我当然同意 OOP 有一些我还没有解决的问题，除了设计模式的形式，它实际上是在解决症状而不是疾病。