类设计的SOLID原则

SOLID原则是面向对象范式的核心

单一职责原则（Single Responsible Principle， SRP）：对于一个类，应该仅有一个引起它变化的原因。其基础是内聚，表示类完成单一功能的程度。
开放—封闭原则（Open Closed Principle，OCP）：类应该对扩展开放，对修改关闭。是SOLID原则中最重要的一个。OCP 的一个原则就是将类之间的耦合到抽象级别。
Liskov替换原则（Liskov Substitution Principle，LSP）：子类型应该能够替换它们的基类型。为了使用LSP，必须要遵循OCP ，违反了LSP 同时也就会违反OCP ，但反过来并不成立。OCP 的关注焦点是抽象耦合，而LSP 尽管也很依赖抽象耦合，但它还严重依赖前置条件（precondition）和后置条件（postcondition）。前置条件是指方法调用前必须要满足的契约，后置条件在方法完成是必须为真。如果前置条件不满足，方法不应该调用；如果后置条件不满足，方法不应该返回。
依赖倒置原则（Dependency Inversion Principle，DIP）：依赖抽象体，不要依赖固定的类。
接口隔离原则（Interface Segregation Principle， ISP）：众多的接口要优于单一的、通用性的接口。
组合重用原则（Composite Reuse Principle，CRP）：优先选择对象的多态组合而不是继承。

　　高内聚的模块更易于理解、维护和重用。内聚是一个定性的测量，很难进行客观的评定。

　　在软件开发中会根据变化频率和重用间关系进行打包，在开发生命周期的早期，系统不稳定而且变化很多，此时应该基于变化的频率打包而不是根据重用打包。当系统逐渐稳定后，再关注基于重用打包，此时变化少得多。

　　最常见的分层模式为展现、业务逻辑以及数据访问三层。但是每个分层中可能会有多个等级。

　　展现层负责构造和渲染用户界面。业务逻辑或领域层包含业务对象，而数据访问层会封装持久化的数据存储以及外部系统的访问。

　　接口要更接近使用它们的类，

　　发布接口是由导出包中公开类的公开方法组成的，它可以被其他的模块调用。

　　使用标准的JAVA，阻止外部类访问你不想公开的类或方法的最简单方式就是使用接口。接口定义了想暴露的方法，而模块中的实现可以定义其他的公开方法。模块的用户应该使用接口进行交互，而不是使用实现。如果不使用转型，模块的用户将不能调用实现类中的方法。

　　外部化配置增加了模块的可重用性，但是降低了可用性。针对环境上下文配置模块方式多种：

配置信息包含在模块中：优势是在模块的默认上下文中很易于使用，不足在于这个默认配置很可能在其他的上下文中不能正常工作。
配置文件没有部署在模块中，但在初始化的时候将它提供给了模块：优势在于模块不再与它的上下文相耦合并且能够跨上下文重用。但是模块每次用于新环境时，必须要提供配置信息。

　　借助模块门面，可以保持一种平衡，也就是创建高重用性的细粒度和轻量级模块，同时又能为开发人员提供便利的方式使用这一组模块。但模块门面所增加的依赖会加大部署相关的复杂性。

　　通过在新的模块中，定义新的类来实现或扩展抽象体，能够更容易地扩展和维护应用。只依赖模块的抽象元素会付出一定的代价：创建实现类的实例时不能再使用new关键字了。作为替代，有如下方案：

对象工厂（object factory）：可以避免依赖模块中具体元素。首先，工厂是应用中唯一引用具体类的地方，添加新的具体类来扩展抽象体会很容易；其次，如果有一些与创建实例相关的规则，那么这些规则就会被封装在工厂中，如果规则发生变化，只需维护一个地方。
动态创建（dynamic creation)：某些情况下，使用Class类比对象工厂更合适。如下场景下会更好：第一种，在Web应用程序中，如果想在服务器启动的时候创建一些特定的类，可以使用Class类并且在启动属性文件中指定要实例化的具体类，通过指定新的类并将其全限定名设置在适当的属性文件中，这样就能够在服务器启动的时候，创建新的类并将其插入应用中；第二种，当使用抽象工厂模式（GOF）时，对于指定如何创建具体的工厂来说，将其指定在属性文件中也是很有用处的。在大多数的场景下，使用对象工厂方式比较多，但也有很多依赖注入框架，如Spring。
OSGi uService：OSGi框架中，在OSGi bundle 启动的时候，uService 能够动态实例化那些注册为uService 服务的类。

　　分离抽象有助于消除模块关系。但是，也会导致要管理更复杂的结构，使用分离抽象时，会面临灵活性和复杂性之间的取舍。通用指导原则如下：