设计模式死了吗?鲍勃大爷认为还没 - unclebobmartin


有些人说设计模式已经死了。真愚蠢! “设计模式”书籍是我们行业中出版的最重要的书籍之一。对于所有专业程序员来说,其中的概念应是基本知识。
 
设计模式就像现实生活中的谚语:这是开放了其他人的经验。
 
假设需要调用10种不同类型的设备,然后再打开它们,我会创建一个DeviceByNameProducer,然后我可能会依靠接口来解决问题,我认为这样会很好!
 
模式作为任何形式的知识都不是关键。对原理的概念性理解是关键。模式只是应用程序的示例,因此并非必须严格了解。
 
“有些人”说对反复出现的问题的优雅解决方案已经死了吗?我不明白。
 
在当今的许多代码中都可以识别它们。我多年前读过Judith Bishop撰写的“ C#3.0中的设计模式”。很棒的书。除非编程会发生巨大变化,否则它们将在那里存在很多年。
 
将模式视为完美是错误的。模式只是我们有时会发现有用的工具。反模式就像不使用眼睛,因为您不能在黑暗中使用它们。这种模式有帮助吗?答案总是“有时”
 
大多数原始模式都是高阶函数的草率替代品。它们不是任何东西的基础。
 
这些模式是我一生中必须经历的最可怕的代码。它丝毫没有帮助软件构建。
 
使用一种函数语言如Clojure,可以大大简化许多最著名的设计模式。
 
问题是看书的人,他们记住了模式,但不了解为什么存在这些模式。(banq注:使用设计模式的上下文场景无法掌握)
  
事实上,GoF设计模式书主要是关于用接口继承(实现)替换实现继承(扩展)
 
设计模式缺少语言特性。早在1996年,Norvig声称Lisp语言具有一流的类型和函数、宏、方法组合、多方法和模块,因此23种模式中的16种模式在Lisp中是不可见的或更简单。
 
最初的GOF模式书开始了一种趋势,现在我们拥有有关企业应用程序模式,云架构模式,分布式计算模式,微服务模式的书籍。所有的好东西!
 
对于面向对象的语言,设计模式可以完美地工作,但是对于像GO这样的语言,则有点尴尬。我一直在寻找关于如何在函数性语言中应用它们而又不会弄乱的好文章。我不确定我会把GO称为一种函数语言,更多是一种过程化语言。
 
设计模式这完全改变了我处理面向对象的方式。就像找到一本描述如何玩游戏的指南书一样,以前我只知道规则。大多数面向对象的书籍都是关于规则的。设计模式涉及战略和战术。
 
banq评:设计模式的应用缺乏明确的上下文场景,导致很多初学者知道掌握23种模式,但是却很少有机会在实践中主动使用,有时为了使用而使用,导致过度设计。设计模式的使用好像只能存在于考试试题中。参考:DDD和OO是有区别的:抽象名称选择很重要?主语语法遮蔽了真理