《设计模式之禅》读书笔记--(1)设计原则

单一职责原则

单一职责原则要求在设计类、接口或方法时要保证功能的单一。例如不要将描述用户信息与行为的方法放到一个类或者接口中，而应该将按职责进行划分。其中，将用户的信息抽取为BO（Business Object，业务对象）；将用户的行为抽取为Biz（Business Logic，业务逻辑）。但在这里最好还将BO与Biz抽象为接口，然后在用一个类去实现这些单一职责的接口，而不应该针对每个接口都设计一个相应的职责单一的类，因为这样会造成类之间的耦合过重与类数量的增加，增加设计的复杂性。

因此，类的设计尽量做到只有一个原因引起变化就可以了。同时，方法也应该做到职责单一。例如，有一个方法要实现修改用户信息，方法内部需要实现修改用户密码，此时应该将修改用户密码相关实现抽取为另一个方法，并在修改用户信息的方法中进行调用。比较典型的应用就是set/get方法，对每个字段的操作都应该实现相应的函数，并在函数命名上加以体现，如void setName(String name)，也不要想着实现一个通用的方法去根据输入参数的不同在方法内部进行判断，如void set(Object obj, Menu options)，不要让别人猜测这个方法可能是用来实现什么逻辑。

里式替换原则

里式替换原则要求只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常。该原则有几点需要注意：

• 如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，此时子类对应方法已经不能完成父类方法要求实现的业务，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。
• 子类可以有自己的个性，但应该尽量避免，因为这要会导致耦合关系更加复杂。
• 覆盖或实现父类的方法时输入参数可以被放大，但不能被缩小。若子类在实现父类方法时，将输入参数缩小，即子类重载父类方法。此时按照里式替换原则将相关业务中的父类替换为子类，我们期望被调用的还是父类的方法，因为我们并没有覆写父类方法，但很可能此处因为输入参数类型的问题而执行子类的方法，而父类方法被隐藏了，这样就造成了逻辑上的混乱。

依赖倒置原则

依赖倒置原则主要表现为以下三点：

• 实现类之间通过接口或抽象类产生依赖关系，而不发生直接的依赖关系。
• 接口或抽象类不依赖于实现类。
• 实现类依赖于接口或抽象类。

采用该原则可以降低类间耦合，增加协同开发的效率。

接口隔离原则

接口隔离原则要求客户端不应该依赖不需要的接口，这就需要在满足单一职责原则的前提下，对接口进行细化，同时接口中的方法尽量少，而不要建立一个庞大臃肿的接口，容纳所有的客户端访问。

因此，开发者需要根据经验和常识决定接口的粒度大小，接口粒度太小，导致接口数据剧增；接口粒度太大，灵活性降低，给整体项目带来无法预料的风险。

最少知识原则

最少知识原则要求一个类应该对自己需要耦合或调用的类知道的最少。例如，安装软件时有步骤一、步骤二、步骤三，这些方法都封装在导向类中，在安装软件时，需要依次调用这些方法。此时，若导向类将这三个方法都声明为public，会导致业务场景类与导向类的关系太过紧密，修改时涉及的面也更大，例如在修改导向类中的这些方法时，还需要对业务场景类中相关调用进行修改。因此，更好的做法是将这三个方法都声明为private，而导向类只公布一个包含这三个方法调用的public方法。

同时，需要注意的是，类与类之间的关系应该建立在类间，而不是方法间，即一个方法中尽量不引入一个类中不存在的对象。

开闭原则

开闭原则的含义是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。该原则主要体现为：

• 抽象约束。通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放，即通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法，同时参数类型、引用对象尽量使用接口或抽象类，而不是实现类，而抽象层则尽量保持稳定，一旦确定即不允许修改。
• 元数据控制模块行为。尽量使用元数据，即配置参数，来控制程序的行为，减少重复开发，元数据可以从文件中获得，也可以从数据库中获得。
• 制定项目章程。
• 封装变化。将相同的变化封装到一个接口或抽象类中；将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。