问似乎无法理解可靠的原则和设计模式

EN

我在大学里上过一门课，花了两个星期的时间研究设计模式，但读了Gang of Four的书却一无所获。对于我这样一个没有太多面向对象编程经验的开发人员来说，理解每种模式的作用以及如何使用它们来解决我的问题是非常困难的。

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

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

让我们来谈谈SOLID：

1. Single responsibility。一个类应该只有一个责任。这意味着，例如，Person类应该只关心关于person本身的域问题，而不是它在数据库中的持久性。为此，您可能希望使用PersonDAO作为示例。Person类可能希望尽可能短地保留其职责。如果一个类使用了太多的外部依赖项(也就是其他类)，那就是这个类有太多职责的症状。当开发人员试图使用对象对现实世界进行建模时，这个问题往往会出现，而且做得太过了。松散耦合的应用程序通常不太容易导航，并且不能准确地模拟现实世界中works.
2. Open关闭的方式。类应该是可扩展的，但不能修改。这意味着将新字段添加到类中是可以的，但更改现有的内容就不是这样了。程序上的其他组件可以依赖于所述field.
3. Liskov替换。如果传递了一个子类dog和一个子类cat，那么需要一个动物类型的对象的类应该可以工作。这意味着Animal不应该有一个叫做bark的方法，因为cat类型的子类不能叫。使用Animal类的类也不应该依赖于属于Dog类的方法。不要这样做“如果这个动物是一只狗，那么(施放动物对狗)叫。如果动物是一只猫，那么(施放动物对猫) meow".
4. Interface隔离原则。保持你的界面尽可能的小。同时也是学生的教师应该同时实现IStudent和ITeacher接口，而不是只实现一个称为IStudentAndTeacher.
5. Dependency inversion principle的大接口。对象不应该实例化它们的依赖项，但应该将它们传递给它们。例如，内部有Engine对象的汽车不应该执行engine = new DieselEngine()，而是应该在构造函数中将engine传递给它。这样，car类将不会耦合到DieselEngine类。