58

我最近正在尝试进入 OOP，但我在SOLID原则和设计模式方面遇到了麻烦。我明白人们为什么要使用它们，而且我也很想使用它们，但我无法完全按照规范开发我的类。我真的很感激任何有助于我理解这些的东西。

4

1 回答 1

123

我在大学上了一门课，花了两周时间围绕设计模式，读了《四人帮》一书，但无济于事。了解每种模式的用途以及如何使用它们来解决我的问题对我来说非常困难，我是一个在 OO 编程方面没有太多经验的开发人员。

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

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

让我们谈谈SOLID：

  1. 单一责任。一个类应该只有一个职责。这意味着，例如，一个 Person 类应该只关心关于人本身的域问题，而不是例如它在数据库中的持久性。为此，您可能需要使用 PersonDAO。Person 类可能希望尽可能缩短其职责。如果一个类使用了太多的外部依赖项（即其他类），则表明该类承担了太多责任。当开发人员尝试使用对象对现实世界进行建模并且太过分时，通常会出现此问题。松散耦合的应用程序通常不太容易导航，并且不能准确地模拟现实世界的工作方式。
  2. 开闭。类应该是可扩展的，但不可修改。这意味着向一个类添加一个新字段是可以的，但改变现有的东西不是。程序上的其他组件可能取决于所述字段。
  3. 里斯科夫换人。如果传递了子类 dog 和子类 cat，则期望动物类型对象的类应该可以工作。这意味着 Animal 不应该有一个名为 bark 的方法，例如，因为 cat 类型的子类将无法吠叫。使用 Animal 类的类也不应该依赖于属于 Dog 类的方法。不要做类似“如果这个动物是狗，那么（把动物扔给狗）吠。如果动物是猫，那么（把动物扔给猫）喵”。
  4. 接口隔离原则。尽量保持你的接口最小。既是学生又是学生的教师应该同时实现 IStudent 和 ITeacher 接口，而不是一个名为 IStudentAndTeacher 的大接口。
  5. 依赖倒置原则。对象不应该实例化它们的依赖关系，但应该将它们传递给它们。例如，内部有 Engine 对象的 Car 不应该执行 engine = new DieselEngine()，而是应该在构造函数中将引擎传递给它。这样，汽车类将不会与 DieselEngine 类耦合。
于 2012-12-03T21:39:04.867 回答