似乎无法理解SOLID原则和设计模式

Question

我最近正在尝试学习面向对象编程，但SOLID原则和设计模式让我感到困惑。我知道它们的好处，也想使用它们，但是我无法理解如何按照规范开发我的类。我非常希望能得到任何有助于理解这些概念的帮助。

- will

---

我认为只有通过工作经验才能对此有良好的理解，重要的是在一个有优秀开发人员的团队中获得经验。 - sll

我认为你应该更具体一些，可能是针对某个原则出现了问题。 - Carlos Gavidia-Calderon

尝试从反模式中学习。尝试编写一个故意违反SOLID建议的小应用程序和一个遵循建议的应用程序，看看哪个更容易编写。 - MatthewMartin

我投票反对重新开放，因为这个问题太过宽泛。我建议阅读一些罗伯特·马丁的文章，他们比《Head-First》书籍有更好的例子。 - Nathan Hughes

可以在以下链接中查看：https://davesquared.net/2009/01/introduction-to-solid-principles-of-oo.html - Md. Sajedul Karim

Answer 1

我曾经上过一门大学课程，其中有两周是关于设计模式的，我也读了四人帮的书，但都没有什么用。对于我这样一个没有太多面向对象编程经验的开发者来说，理解每个模式的作用以及如何使用它们来适应我的问题非常困难。

真正让我明白的那本书是Head First设计模式。它首先展示了一个问题，不同的开发者考虑的方法，然后展示他们最终如何使用设计模式来解决它。它使用了非常简单的语言，并保持了书籍的趣味性。

设计模式最终成为了描述解决方案的一种方式，但你不必须将你的类适应这个解决方案。把它们看作是指导广泛问题的好的解决方案的指南。

现在让我们谈谈SOLID原则：

1. 单一职责原则. 一个类应该只有一个职责。这意味着例如Person类只需关注于自己的领域问题，而不必关注数据库中是否持久化。为此，您可能需要使用PersonDAO。Person类可能希望尽可能缩短其责任。如果一个类使用了太多外部依赖（即其他类），那就意味着该类承担了太多的责任。当开发人员试图使用对象来模拟现实世界并将其推向极致时，通常会出现这个问题。松耦合的应用程序通常不容易导航，也不能完全模拟现实世界的运作方式。
2. 开闭原则. 类应该是可扩展的，但不可修改的。这意味着添加一个新字段到一个类中是可以的，但改变现有的东西是不行的。程序中的其他组件可能依赖于该字段。
3. 里氏替换原则. 如果一个类期望一个类型为动物的对象，则传递子类dog和子类cat应该可行。这意味着Animal不应该有一个名为bark的方法，因为类型为cat的子类无法吠叫。使用Animal类的类，也不应该依赖于Dog类所拥有的方法。不要做类似于“如果这个动物是狗，那么（将动物强制转换为狗）就会吠叫。如果动物是一只猫，则（将动物强制转换为猫）就会喵喵叫。
4. 接口隔离原则. 使您的接口尽可能小。也就是说，一个既是老师又是学生的人应该实现IStudent和ITeacher接口，而不是一个名为IStudentAndTeacher的大接口。
5. 依赖倒置原则. 对象不应该实例化其依赖项，而应该将它们传递给它们。例如，具有Engine对象的Car不应该执行engine = new DieselEngine()，而是应该在构造函数中传递该引擎。这样，Car类将不与DieselEngine类耦合。

- Uri

---

推荐这本书是个好主意。《GoF设计模式》这本书很难理解，而《Head First》绝对是读过之后能让你进阶编程的必读之书。 - Bob Horn

1) 改变应该有一个原因，这与责任不同。 2) 不，您不应该修改类。扩展与继承是相同的事情。3) 如果它还有一个CanBark方法，那么它可以有一个Bark方法 ;) 4 正确，但是例子有点无聊 ;) 5 这就是依赖注入。依赖反转表示您应该依赖于抽象，并且高级模块应该依赖于低级模块而不是相反。 - jgauffin

开始读那本书了。它真的很有帮助。谢谢。 - will

我读过的最好的 Liskov 原则例子。 - lolololol ol

@jgauffin - 链接无法使用。 - Michu93