匿名用户
我在大学里上过一个花了两周时间学习设计模式的课程，读了四人帮的书，但没有用。理解每种模式的用途以及如何使用它们来解决我的问题对我来说非常困难，我是一个没有太多OO编程经验的开发人员。
真正让我喜欢的书是《头先设计模式》。它首先展示了一个问题，开发人员考虑的不同方法，然后他们如何最终使用设计模式来解决问题。它使用了一种非常简单的语言，使本书非常吸引人。
设计模式最终成为描述解决方案的一种方式，但是您不必使您的类适应解决方案。更多地把它们看作是一个向导，为大量问题提供一个好的解决方案。
让我们谈谈SOLID：
- 单一责任。一个班级应该只有一个责任。这意味着，例如，Person类应该只关注与个人本身相关的域问题，而不关注其在数据库中的持久性。为此，您可能希望使用PersonDAO作为示例。Person类可能希望尽可能缩短其职责。如果一个类使用了太多的外部依赖项（即，其他类），这表明该类有太多的责任。当开发人员试图使用对象来模拟真实世界，并且做得太过火时，就会出现这个问题。松散耦合的应用程序通常不太容易导航，也不完全模拟真实世界的工作方式
- 打开关闭。类应该是可扩展的，但不能修改。这意味着向类中添加新字段是可以的，但更改现有内容则不是。程序中的其他组件可能取决于所述字段
- Liskov替代。如果传递了子类dog和子类cat，则需要动物类型对象的类应该可以工作。这意味着Animal不应该有一个叫bark的方法，因为cat类型的子类不能吠叫。使用Animal类的类也不应该依赖于属于类Dog的方法。不要做类似“如果这个动物是狗，那么（把动物扔给狗）吠叫。如果动物是猫，那么（将动物扔给猫）喵喵叫”的事情
- 界面隔离原则。尽可能保持最小的界面。同样是学生的教师应该同时实现IStudent和ITeacher接口，而不是一个称为IStudentAndTeacher的大接口
- 依赖反转原则。对象不应实例化其依赖项，但应将它们传递给它们。例如，内部有Engine对象的Car不应该执行Engine=new DieselEngine（），而是应该在构造函数中将引擎传递给它。这样，汽车类将不会耦合到柴油发动机类
