设计模式不是 OOP 原则的扩展吗？为什么这两个概念要分开处理？如果知道设计模式的人一定会成为 OOP 专家，我们能相信吗？
【问题讨论】：
标签： design-patterns oop
Design Pattern 是针对常见编程问题的久经考验的解决方案。它不一定是面向对象的编程问题，但这是当今最常见的问题。
对于很多人来说，学习编程并不难。这就像玩乐高积木一样：您可以根据需要将一些不同的部件拼凑在一起。有时你会做一些很酷的事情，但大多数时候你会做废话=）。通常，你玩的时间越长，你的表现就越好。
学习设计模式就是学习构建程序的好方法。您实际上是在阅读几十年来一直在构建事物的人们的建议。他们将最常见的解决方案提炼成简单易懂的知识花絮，并带有令人难忘的名字。这就像数字时代的学徒：你的长辈正在给你最好的建议。你可以接受它并领先于游戏，或者忽略它并重复他们的所有错误。
为什么要分开对待设计模式和 OOP？ 因为它们是不同的主题。一般来说，您学习编程，然后学习如何思考编程。我希望它是相反的方式，但我没有屏住呼吸。
了解设计模式的人一定是 OOP 专家吗？不。
【讨论】：
设计模式和面向对象编程没有必要相关。碰巧有大量的设计模式涉及面向对象编程。
设计模式是一种常用的程序创建方法。为一个领域寻找通用模式语言的方法可以扩展到函数式编程或桥梁构建，或者在建筑中找到它的起点。 OO 是一种特定的概念范式，某些编程模式适合它。
情况就像一个维恩图 - 方法并不对立，但它们并不相同，并且它们在逻辑 级别上运作。
【讨论】：
设计模式不是 OOP 原则的扩展吗？为什么要分开处理这两个概念？
“设计模式”是关于 OOP 原则的，主要是由于历史事故。
我相当肯定 ML 黑客早在 GoF 书出版之前就在谈论代数数据类型的折叠。这是一个常见问题的可靠解决方案：您想根据某些代数数据类型的内容计算单个值。我认为map 也是如此。
我认为发现和编码解决方案模板的一般（元？）实践已经很老了——这不是“最佳实践”的本质吗？
我认为将 DP 和 OOP 分开处理的原因是因为尽管它们重叠——人们会认为 OOP 最佳实践与 OOP 原则有关——但有一些独立性：谈论设计是有意义的非 OO 设置中的模式。
【讨论】：
我认为你应该拿起任何一本设计模式书，然后阅读介绍。一旦你了解了什么是设计模式，你就会回答这个问题。
【讨论】：
实际上，设计模式和 OOP 之间并没有任何关系。顾名思义，它们是用于实现设计的模式（或“配方”）。几乎所有你会使用的语言都有“设计模式”，但碰巧《四人组》一书侧重于 OO 设计模式。
了解 OO 设计模式可能是一个积极的指标，但在采访某人（或试图衡量他们的专业水平）时，我会查看他们熟悉的模式的复杂性以及良好的知识何时/何地使用模式。我已经看到开发人员锁定了“金锤”之类的模式，并在不一定适用的地方使用它。
因此，就像一本食谱书并不能使一个人成为大厨一样，OO 设计模式的知识并不一定能使一个人成为 OO 专家。
【讨论】：
设计模式是解决 OOP 编程中出现的问题的常用方法。在确定如何处理某种情况时，了解设计模式可以节省一些时间。
某些设计模式允许您完成原本不可能或复杂的事情，例如Visitor Pattern，它允许一组类在不知道更改的情况下获得新功能。使用普通的 OOP 技术，可以创建每个类实现的接口或虚拟方法。这违反了 OOP open/closed principle。
我不会说知道设计模式的人是 OOP 专家。
程序员一直在使用模式，而从未研究过它们，因为它们在 Java 和 .NET 框架中被广泛使用。大多数 Java IO 命名空间由利用 Decorator pattern 的类组成。知道这一点并不能使某人或多或少成为 OOP 方面的专家，但它可以帮助理解事物。
【讨论】：
面向对象编程是一种编程方法或编程概念，它将代码组织成对象和对象之间的关系。设计模式会建议经过验证的成功方法来构造类型/对象以解决程序中的特定场景。
这是一个有限的定义。
【讨论】：
我认为 OOP 原则是一组工具，设计模式可以用来生成一个好的程序。
【讨论】：
设计模式不是 OOP 原则的扩展：我认为答案应该是否定的
为什么要分开对待设计模式和 OOP？
OOP 原则 - 实际上是关于在设计/定义类时应该遵循哪些约束/主题（业务对象的技术表示）..类的行为方式..应该采取什么行动删除任何其他类依赖以使其正常运行.. 以及更多.. 这就是众所周知的 SOLID 原则
对于那些不知道这一点的人，SOLID 是第一个的首字母缩写词 面向对象设计的 5 条原则：
- 单一职责原则
- 开闭原则
- Liskov 替换原则
- 接口隔离原则
- 依赖倒置原则
设计模式 - 主要是关于您希望如何定义/维护应用程序中的编码标准。如何以标准方式简化应用程序的执行流程......使其易于维护。 .
在下面的示例中.. 定义了一种设计模式.. 它是关于每个开发人员应该如何创建对象..
//Register
builder.RegisterType<ConsoleOutput>().As<IOutput>();
builder.RegisterType<TodayWriter>().As<IDateWriter>();
Container = builder.Build();
//Create instance
var writer1 = Container.Resolve<IOutput>();
writer1.Write("HelloWorld");
var writer2 = Container.Resolve<IDateWriter>();
writer2.WriteDate();
架构师想要创建一个设计模式，让每个开发人员 必须在类的顶部创建一个接口..并且接口和类必须在工厂中注册才能创建一个实例..因为 建筑师想要一些统计报告，比如有多少 注册了类（业务对象）或创建了多少个对象 完成单个模块（现在可以轻松实现 工厂的'RegisterType'和'Resolve'函数内部代码）..
所以，现在可能很清楚设计模式和 OOP 是
very different aspect
我们能相信如果知道设计模式的人一定会成为 OOP 专家吗？ - 应该是……但不是强制性的！
【讨论】：
面向对象编程本身就是一种设计模式。
【讨论】：