我在大学上了一堂课，花了两周时间围绕设计模式，阅读Gang of Four书无济于事。了解每个模式的用途以及如何使用它们来解决我的问题对我来说非常困难，一个在OO编程方面没有太多经验的开发人员。
真正让它为我点击的那本书是 Head First Design Patterns 。它首先展示了一个问题，开发人员考虑的不同方法，然后他们最终如何使用设计模式来修复它。它使用非常简单的语言，使书非常吸引人。
设计模式最终成为描述解决方案的一种方式，但您没有来使您的类适应解决方案。将它们更多地视为指导，以便为各种各样的问题提供良好的解决方案。
我们来谈谈SOLID：
- 单一责任。一堂课应该只有一个责任。这意味着，例如，Person类应该只担心关于此人本身的域问题，而不是例如它在数据库中的持久性。为此，您可能希望使用PersonDAO作为示例。 Person类可能希望尽可能地保持其职责。如果一个类使用了太多外部依赖项（即其他类），那么这就是该类具有太多职责的症状。当开发人员尝试使用对象对现实世界进行建模并将其放得太远时，通常会出现此问题。松散耦合的应用程序通常不易于导航，并且不能完全模拟现实世界的工作方式。
- 已关闭。类应该是可扩展的，但不可修改。这意味着向一个类添加一个新字段很好，但改变现有的东西不是。该计划的其他组成部分可能取决于所述领域。
- Liskov替换。如果传递子类dog和子类cat，则期望类型为animal的对象的类应该有效。这意味着Animal不应该有一个名为bark的方法，例如，因为cat类型的子类将无法吠叫。使用Animal类的类也不应该依赖于属于Dog类的方法。不要做“如果这种动物是狗，然后（将动物投入狗）树皮。如果动物是猫，那么（将动物投入猫）喵”。
- 界面隔离原则。保持您的界面尽可能小。同时也是学生的教师应该同时实现IStudent和ITeacher接口，而不是一个名为IStudentAndTeacher的大型接口。
- 依赖性倒置原则。对象不应该实例化它们的依赖项，但是应该将它们传递给它们。例如，内部有Engine对象的Car不应该执行engine = new DieselEngine（），而是应该在构造函数上将引擎传递给它。这样汽车类就不会与DieselEngine类相结合。