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

Question

我试图最近进入OOP，并且在SOLID原理和设计模式方面遇到问题。我明白为什么人们会使用它们，我也很想使用它们，但是我无法将自己的课程发展为规范。我真的很感激任何能够帮助我理解这些的东西。

Answer 1

我在大学读过一堂课，花了两个星期的时间学习设计模式，并且读了Gang of Four这本书无济于事。了解每种模式的服务内容以及如何使用它们来适应我的问题对我来说非常困难，这是一个在面向对象编程方面没有太多经验的开发人员。

真正让它点击的书是Head First Design Patterns。它首先展示一个问题，开发人员考虑的不同方法，然后他们如何最终使用设计模式来解决问题。它使用一种非常简单的语言，并保持这本书非常吸引人。设计模式最终成为描述解决方案的一种方式，但您不需要就可以让使您的类适应解决方案。可以把它们看作是一个指导方针，为各种问题提供了一个很好的解决方案。

讲起SOLID：

1. 单一职责。一个班级应该只有一个责任。这意味着，例如，一个Person类只应该担心关于该人本身的域问题，而不是例如它在数据库中的持久性。为此，您可能想要使用PersonDAO。 Person类可能希望尽其最短的责任。如果一个类正在使用太多的外部依赖（也就是其他类），那就是这个类承担了太多责任的症状。当开发人员尝试使用对象对现实世界进行建模并采用它时，通常会出现这个问题。松散耦合的应用程序通常不太容易导航，并且不能准确模拟真实世界的工作方式。
2. 开放已关闭。类应该是可扩展的，但不可修改。这意味着给一个类增加一个新的字段很好，但改变现有的东西却不行。程序上的其他组件可能取决于所述字段。
3. Liskov替代。如果通过了一个子类的狗和一个子类的猫，那么期望类型为动物的类应该可以工作。这意味着动物不应该有一个叫做树皮的方法，因为cat类型的子类将无法吠叫。使用Animal类的类也不应该依赖于属于类Dog的方法。不要做像“如果这只动物是狗，然后（把动物对狗）树皮，如果动物是猫然后（把动物对猫）喵喵叫”。
4. 接口隔离原理。保持您的界面尽可能最小。同样是学生的老师应该实施IStudent和ITeacher接口，而不是称为IStudentAndTeacher的单个大接口。
5. 依赖倒置原理。对象不应该实例化它们的依赖关系，但它们应该传递给它们。例如，内部具有Engine对象的Car不应该执行engine = new DieselEngine（），而应该将引擎传递给构造函数。这样汽车级别将不会与DieselEngine类相关联。