可能重复:
设计模式真的是语言弱点吗?
在花了数年时间翻阅有关 OOP 和 OOP 技术的书籍,并且最近越来越多地参与编程的函数式风格之后,可以推断设计模式是指向整个面向对象编程的系统性问题的指针是否公平。面向对象编程中是否存在一个根本缺陷(不要与设计混淆),在通过封装处理状态时,导致了越来越多的模式来解决这种范式的问题。
我对此没有得出任何结论,但我的“直觉”感觉是,OOP 的范式可能存在更严重的错误。
封装的想法是否会导致比他们解决的问题更多的问题。
可能重复:
设计模式真的是语言弱点吗?
在花了数年时间翻阅有关 OOP 和 OOP 技术的书籍,并且最近越来越多地参与编程的函数式风格之后,可以推断设计模式是指向整个面向对象编程的系统性问题的指针是否公平。面向对象编程中是否存在一个根本缺陷(不要与设计混淆),在通过封装处理状态时,导致了越来越多的模式来解决这种范式的问题。
我对此没有得出任何结论,但我的“直觉”感觉是,OOP 的范式可能存在更严重的错误。
封装的想法是否会导致比他们解决的问题更多的问题。
一个很好的问题,也是我前段时间想到的。这是我的结论\意见:
面向对象编程的思想并非没有缺陷,但确实提供了最完整的设计范式。如果问题域表达得当,明确定义的对象,知道自己的职责,可以以相当优雅的方式进行交互,这与对象的真实世界交互非常相似。(或想法)。
为了使一些更抽象的概念、具体的概念,OOP 做出一些断言的陈述。(就像封装一样,不要暴露超出你必须和对象责任的范围)。
像所有一般假设一样,也会有例外,通常是一个好主意,可能不适合手头的特定问题。OOP 涵盖了几乎所有设想的问题(与 AOP 甚至更复杂的语义建模不同,它迎合特定类型的问题),这一事实也无济于事。
因此,在某些情况下,当您需要做出例外并远离 OOP 断言时,设计人员需要一种方法来保持良好设计的界限,这样他们就不会偏离公认的设计实践太多。
所以设计模式,对我来说只是问题的案例研究,不会被 OOP 的一些核心断言所服务。除了解决方案的协作和整理之外,设计模式还有助于增强 OOP。(特别是对于新手设计师)。
注意:大多数时候,不需要设计模式。使用模式需要有明确的理由。我知道,一些新手,试图实现一些设计模式,只是因为他们了解它们(有时不是新手;))。它的方钉,圆孔问题
不。尽管您看到的设计模式略有不同,但您当然仍然可以在功能代码中看到设计模式。基本区别与缺乏状态几乎没有关系(如果有的话)。相反,它主要源于(大多数)函数式语言,它们在创建函数时提供了足够多的多功能性,以至于另一种语言中的“设计模式”简单地变成了函数式语言中的函数。
如果您在具有状态的语言中提供(大致)相似级别的多功能性,您可以获得相同的效果。例如,现代 C++ 设计的大部分介绍都在捍卫设计模式可以编码为模板的立场(并且本书的大部分内容都是作为模板实现的设计模式)。
好问题,几周前我开始想知道这个我自己,同时更多地了解 Python 和 Scala。
我认为是和不是。OOP 和状态封装肯定存在一些内在问题,但并不是说 OOP 本身就是一种糟糕的做事方式。我认为问题在于,当你只有一把锤子时,一切都变成了钉子。OOP 在某些方面非常有用,首先想到的是 GUI,但函数式编程也有非常明显的好处。
值得注意的是,Scala 等较新的函数式编程语言并没有丢弃对象。
我没有详细考虑过这个问题,但我当然同意 OOP 有一些我没有看到解决的问题,除了以设计模式的形式,它真正解决的是症状而不是疾病。
我在重复我的一个基本理论,但模型就是这样——只有模型。OOP 定义的模型是构建程序的一种非常有效的方法,对于许多应用程序编程领域来说,是完全合适的。对于某些问题空间,模型可能会变得越来越有效(或效率较低,或两者兼而有之)。
物理学存在一个潜在的隐喻。多年来,牛顿物理学在模拟运动、时间和空间定律方面(在欧几里得几何和螺旋几何的帮助下)做了(事实上仍然如此)一项了不起的工作。但是当科学开始探索问题空间的微观和宏观方面时,牛顿物理学(和欧几里得/球面几何)开始崩溃。因此,我们现在有了相对论和量子力学。它们分别在宏观和微观层面上对宇宙进行了出色的建模,但过于复杂,无法用作日常人类规模事件的描述。
在很多情况下,当考虑到建模现实世界问题和人类交互以供线性机器消费和处理的复杂性时,OOP 对应用程序编程非常有效。正如上面有人观察到的那样,没有灵丹妙药。我的印象(从未使用过 C++)是,试图成为多范式的语言也变得更加复杂,而且对于更容易用更高级别、更有针对性的语言处理的小问题,不一定同样有效。很像量子力学和/或相对论(我的意思是,真的,有人对在高速公路上以 60 英里/小时的速度行驶时的质量和速度之间的关系感兴趣吗?或者当你到达洛杉矶时,你期望它在哪里的概率?)。
在我的印象中,坚持 qa 特定模型很重要,只要该模型适合问题空间。当这种情况不再成立时,模型可能需要发展,并且会对此产生抵制。将尝试将问题空间强制转换为不适合的模型(再次回顾物理学史,或检查以太阳系为中心的模型的演变,并包括关键词“本轮”)。
以上所有只是我对事物状态的最好理解,如果我在某个地方错过了标记,我很高兴听到一些相反的消息。
我认为当您尝试将单一编程范式应用于问题时,总会出现问题。这就是我喜欢 C++ 的原因:它是多范式的;它不会强迫您采用一套解决方案。