似乎无法理解 SOLID 原则和设计模式 [关闭]答案

【问题标题】：Can't seem to understand SOLID principles and design patterns [closed]似乎无法理解 SOLID 原则和设计模式 [关闭]
【发布时间】：2012-11-21 10:37:30
【问题描述】：

我最近正在尝试进入 OOP，但在 SOLID 原则和设计模式方面遇到了麻烦。我明白人们为什么要使用它们，而且我也很想使用它们，但我无法全神贯注地按照规范开发我的类。我真的很感激任何有助于我理解这些的东西。

【问题讨论】：

我认为只有工作经验才能很好地理解这一点，重要的是拥有优秀开发人员的团队经验
我认为你应该更具体一点，也许是给你带来麻烦的特定原则。
尝试学习反模式。尝试编写一个故意违反 SOLID 建议的小应用程序和一个遵循建议的应用程序，看看写什么不那么痛苦。
投票反对重新开放，因为这太宽泛了。我建议阅读 Robert Martin 的一些文章，它们的示例比 Head-First 书要好得多。
也许 SOLID 图会有所帮助。 swarch.blog/the-five-principles-for-solid-software-design

标签： oop design-patterns solid-principles

【解决方案1】：

我在大学上了一门课，花了两周时间围绕设计模式，读了Gang of Four 的书，但无济于事。对于我这个在 OO 编程方面没有太多经验的开发人员来说，了解每种模式的用途以及如何使用它们来解决我的问题非常困难。

真正让我点击的书是Head First Design Patterns。它首先显示一个问题，开发人员考虑的不同方法，然后他们如何最终使用设计模式来修复它。它使用非常简单的语言，使这本书非常吸引人。

设计模式最终成为描述解决方案的一种方式，但您没有必须使您的类适应解决方案。将它们更多地视为指南，为各种问题提供良好的解决方案。

我们来谈谈 SOLID：

单一责任。一个类应该只有一个职责。这意味着，例如，一个 Person 类应该只关心关于人本身的域问题，而不是例如它在数据库中的持久性。为此，您可能需要使用 PersonDAO。 Person 类可能希望尽可能缩短其职责。如果一个类使用了太多的外部依赖项（即其他类），则表明该类承担了太多责任。当开发人员尝试使用对象对现实世界进行建模并且太过分时，通常会出现此问题。松散耦合的应用程序通常不太容易导航，并且不能准确地模拟现实世界的工作方式。
开闭。类应该是可扩展的，但不可修改。这意味着向一个类添加一个新字段是可以的，但改变现有的东西不是。程序中的其他组件可能取决于所述字段。
里氏替换。如果传递了子类 dog 和子类 cat，则期望动物类型对象的类应该可以工作。这意味着 Animal 不应该有一个名为 bark 的方法，例如，因为 cat 类型的子类将无法吠叫。使用 Animal 类的类也不应该依赖于属于 Dog 类的方法。不要做类似“如果这个动物是狗，那么（将动物对狗）吠。如果动物是猫，那么（将动物对猫）喵”。
接口隔离原则。尽量保持你的接口最小。既是学生又是学生的教师应该同时实现 IStudent 和 ITeacher 接口，而不是一个名为 IStudentAndTeacher 的大接口。
依赖倒置原则。对象不应实例化它们的依赖关系，但应将它们传递给它们。例如，内部具有 Engine 对象的 Car 不应该执行 engine = new DieselEngine()，而是应该在构造函数中将引擎传递给它。这样，汽车类就不会与 DieselEngine 类耦合。

【讨论】：

图书推荐+1。 GoF 设计模式书很难理解。 Head First 这本书绝对是进入下一级别编程的必读书籍。
1) 它应该有一个改变的理由。这与一项责任不同。 2) 不，您根本不应该修改类。扩展与继承是一回事。 3) 如果它还具有CanBark 方法，则它可以具有Bark 方法。 ;) 4 正确，但很蹩脚的例子 ;) 5 那是依赖注入。依赖倒置说你应该依赖抽象，而更高级别的模块应该依赖于更低级别的模块，反之亦然。
开始读那本书。这是一个重要的帮助。谢谢。
我读过的 Liskov 最好的例子。
@SudipBhandari：问题已经结束，但我已经在我的博客中写了一些关于solid 的帖子：blog.gauffin.org/tag/solid