weixin_37711738的博客

面向对象的设计原则是指导面向对象设计的基本思想，是评价面向对象设计的价值观体系，也是构造高质量软件的出发点。抽象、封装、多态等概念就是最基本的设计原则。

为什么设计模式能够有效地解决设计问题，它们又是如何设计出来的，该如何学习和使用这些模式呢？

子类型（subtype） 必须能够替换它们的基类型（base type）​。换一个角度来理解，对于继承层次的设计，要求在任何情况下，子类型与基类型都是可以互换的，那么该继承的使用就是合适的，否则就可能出现问题。即子类型不能添加任何基类型没有的附加约束。为了避免子类型针对基类型的行为添加附加的约束（即违背LSP）​，基类型中应该只提供尽量少的必需的行为，而且不针对这些行为进行任何实现。此时，那些基类型往往就是抽象类（行为没有任何实现）​，甚至是接口。

变化是永恒的主题，不变是相对的定义”​。软件系统也是如此，任何系统在其生命周期中都需要有应对变化的能力，这也是体现设计质量的一个最重要的功能。那么，什么样的设计才能应对需求的变更，且可以保持相对稳定呢。

按照传统的设计方案，首先设计订单访问接口IOrder，该接口提供了订单类对外公布的所有操作，包括查询订单（getOrder）​、添加订单（insertOrder）​、修改订单（modifyOrder）和删除订单（deleteOrder）​，然后定义订单类（Order）来实现这些接口。而管理后台需要的管理接口IOrderForAdmin首先继承已有的接口，并添加其他相关的行为。由于只为订单类提供了一个“肥”接口IOrder，因此，门户网站、前台系统和管理后台3个外围系统都通过该接口来使用订单类。

因此，要合理评估类的职责，结合业务场景考虑职责的相关性，从而将不相关的职责相互分离，达到SRP所要求的类的内聚性。在该设计方案中，保留了Rectangle类中的与数学模型相关的职责，而将GUI方面的职责封装到一个新的GUIRectangle类中。同时，不同的职责耦合在同一个类中，一个职责的变化可能会影响其他职责，从而引发“脆弱性”的“臭味”​。为此，类设计应遵从SRP，应建立高内聚的类。因此，一个好的设计方案是将其中的一类职责分离出来，从而保持每一个类处理一类职责，从而满足SRP。

这是因为抽象的事物不同于具体的事物，抽象的事物发生变化的频率要低，让高层模块与底层模块都依赖于一个比较稳定的事物比去依赖一个经常发生变化的事物的好处是显而易见的。在该框架中，通过XML配置文件建立接口和具体类之间的关系，IoC容器通过该配置文件来做具体的新建的工作，这样在实际应用中，只需要修改配置文件就能换成不同的具体类，从而不需要修改任何代码了。在传统的自顶向下、自底向上的编程思想中，通过对模块的分层形成不同层次的模块，最上层的模块通常都要依赖下面的子模块来实现，从而就形成了高层依赖底层的结构。

该准则是由Karl Lieberherr等在一个叫Demeter的项目中提出来的，用于解耦因对象结构的变化和不稳定而导致与该对象耦合在一起的代码。其核心思想就是要求一个类尽量只与它的直接对象交互，避免与间接对象交互，这样就可以与最少的类产生耦合，从而使整个系统的耦合度保持最低。该准则给出了在一个方法内应该向哪些对象发送消息的限制，规定在较少的操作，操作的关联度很高，其任务也比较单一；该准则给出了在一个方法内应该向哪些对象发送消息的限制，规定在一个方法中，消息只能发往以下对象。◆ 该方法内部创建的对象。