Java对象设计通用原则之核心原则

Posted 2020-08-20

　　由于对象设计的核心是类，所以下面的原则也都基本都是讨论类的设计问题，其它类型的元素都比较简单，基本上也符合大多数这里列出的原则。

　　前面我们分析完了对象设计的基本原则，这里我将重新温习一下对象设计的核心原则 - SOLID原则。几乎所有的设计模式都可以看到这些原则的影子。

 

单一职责原则(SRP)：做一个专一的人

　　单一职责原则的全称是Single Responsibility Principle，简称是SRP。SRP原则的定义很简单：

即不能存在多于一个导致类变更的原因。简单的说就是一个类只负责一项职责。

　　让一个类仅负责一项职责，如果一个类有多于一项的职责，这是比较脆弱的设计。因为一旦某一项职责发生了改变，需要去更改代码，那么有可能会引起其他职责改变。所谓牵一发而动全身，这显然是我们所不愿意看到的，所以我们会把这个类分拆开来，由两个类来分别维护这两个职责，这样当一个职责发生改变，需要修改时，不会影响到另一个职责。

　　做且只做好一件事，这一条原则其实不仅仅适用于对象，也同样适用于函数，变量等一切编程元素。当然在商业模式中，将一件事做到极致就是成功，我个人觉得这一条也还是成立的。

　　随便举个例子，如果大家有深入研究过迭代器的思想的话，那其实就是把存储数据和遍历数据的职责分开了，集合只负责实现存储数据的功能，而迭代器完成遍历数据的功能。

　　再说我看到过的一个例子：说有一个辅助类CommonUtil，在这里面提供了所有不能归入其他模块的辅助方法，它的结构如下：

public class CommonUtil
{
 #region Canvas Helpers
 public void M1() { }
 //...
 #endregion
 
 #region Screen Helpers
 public void M2() { }
 //...
 #endregion
 
 #region Size Helpers
 public void M3() { }
 //...
 #endregion
 
 #region Data Helpers
 public void M4() { }
 //...
 #endregion
}

各位，你觉得这个类写的怎么样？

　　这里面放进了各种不同类型的辅助方法，每个模块有辅助方法需要找地方放的时候，人们都是自觉的找到了这个类，于是这个类在每个Release中都不断有新成员加入，于是最终变成了一个庞然大物，使用的时候，光看函数列表都够大家喝一壶了。

　　我的想法是，为什么不拆分成4个小类，每个类专门负责某一类型辅助功能呢？

 

 

开放封闭原则(OCP)：改造世界大部分不是破坏原来的秩序

　　开放封闭原则全称是Open Closed Principle， 简称OCP， 该原则的定义是：

软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。

这条原则是所有面向对象原则的核心。

　　软件设计所追求的第一个目标就是封装变化、降低耦合，而开放封闭原则正是对这一目标的最直接体现。其它的原则或多或少都是为了这个目标而努力的，例如以Liskov替换原则实现最佳的、正确的继承层次，就能保证不会违反开放封闭原则。

　　软件设计所最求的第二个目标就是重用。这个是继承机制的核心动力。由于通常来说抽象的东西最稳定，最不容易变化，所以抽象与继承是实现开闭原则强大的工具，但不是唯一工具，后面我们会说到实现开闭原则的另一个更加强大，更加灵活的工具：组合。

　　一言以蔽之，继承与组合是封装变化，降低耦合的不二法门。能否合理的使用继承和组合是体现一名码农水平高低的又一标准。

　　在实际的代码中，添加新的功能一般意味着新的对象，一个好的设计也意味着这个新的修改不要大幅度波及现有的对象。这一条理解起来最简单，实施起来却是最困难。无数的模式和解耦方法都是为了达到这个目的而诞生的。

　　看一个经典的例子：

public class Component
{
 public enum Status
 {
  None,
  Installed,
  Uninstalled
 }
 
 Status m_status = Status.None;
 
 void Do()
 {
  switch (m_status)
  {
   case Status.None:
    Console.WriteLine("Error...");
    break;
   case Status.Installed:
    Console.WriteLine("Hello!");
    break;
   case Status.Uninstalled:
    Console.WriteLine("Error...");
    break;
   default:
    break;
  }
 }
}

　　我们这里定义了一个组件，用户动态加载，加载完了以后程序就可以用了，为了处理方便，我们给组件定义了一些状态，在不同的状态下，这个组件有不同的行为，于是就有了上面的代码：enum定义状态，函数中使用switch实现路由。

　　使用switch分支是一种经典的做法，当组件的状态类型不存在变化的可能时，该段代码无可挑剔，堪称完美。

　　可是在实际项目中，过了一阶段，我们发现组件的状态不够，比如说我们需要处理组件还未配置时的行为，于是我们在枚举中加了一个状态：Configured，然后在switch中加了一个分支。 

　　又过了一阶段，我们又发现还需要处理组件还未初始化时的行为，于是我们在枚举中又加了一个状态：Initialized，然后在switch中加了一个分支。

　　至于以后是否还需要别的状态，我们目前不得而知，应该说还是有可能的。

　　上面这个行为是严重违反开闭原则的，这个不用多讲了吧。那么如何改进呢？使用我们最强大的工具吧：使用继承或/和组合封装变化点。

　　这里我们分析一下，该组件存在变化的地方就是组件的状态，这是一个变化点，对于变化点，对于变化点不要手软，封印它。

public class ComponentStaus
{
 public virtual void Do() { }
}
public class ComponentNone : ComponentStaus
{
 public override void Do() { Console.WriteLine("Error..."); }
}
public class ComponentInitialized : ComponentStaus
{
 public virtual void Do() { Console.WriteLine("Hello!"); }
}
 
public class Component
{
 ComponentStaus m_status = new ComponentNone();
 
 public void ChangeStatus(ComponentStaus newStatus)
 {
  m_status = newStatus;
 }
 
 public void Do()
 {
  m_status.Do();
 }
}

　　在上面的例子中，我们发现了变化点，然后抽象出一个基类放在那，然后使用继承机制，让子类去演绎变化。当我们需要添加新的状态Configured的时候，我们只要添加一个新的子类ComponentConfigured，让它从ComponentStaus继承，并重写Do方法即可。使用的时候，在合适的时机(如事件处理中)把该子类的实例传给Component就可以了，当然也有可能是Component自己处理事件或方法时自己修改该状态实例。

　　能看到开闭原则的影子吗？(当然，不要妄想对修改完全封闭，这个是不可能的，就像组件之间零依赖是不可能的一样)

 

里氏替换原则(LSP)：长大后，我就成了你

　　里氏替换原则全称Liskov Substitution Principle，简称 LSP，它的定义是：

任何基类可以出现的地方，子类一定可以出现。

　　LSP原则是继承复用的基石，只有当派生类可以替换掉基类，软件的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。

　　LSP原则保证了继承的正确实现。它希望子类不要破坏父类的接口成员。一旦破坏了，就如果人与人之间破坏合同一样，有时候会很糟糕。

　　这个原则看起来也很容易，但是却也很容易和现实中的概念混淆，看个经典的小例子：长方形与正方形问题。

　　在我们小学学数学的时候，就知道正方形是特殊的长方形，于是写代码的时候，自然的正方形类就继承自长方形了，代码如下：

public class Program
{
 static void Main(string[] args)
 {
  Rectangle rect = new Rectangle();
  rect.setWidth(100);
  rect.setHeight(20);
  Console.WriteLine(rect.Area == 100 * 20);
 
  Rectangle squ = new Square();
  rect.setWidth(100);
  rect.setHeight(20);
  Console.WriteLine(squ.Area == 100 * 20);
 }
}
 
class Rectangle
{
 public double m_width;
 public double m_height;
 
 public virtual void setWidth(double width) { m_width = width; }
 public virtual void setHeight(double height) { m_height = height; }
 
 public double Area
 {
  get { return m_width * m_height; }
 }
}
 
class Square : Rectangle
{
 public override void setWidth(double width)
 {
  m_width = width;
  m_height = width;
 }
 
 public override void setHeight(double height)
 {
  m_width = height;
  m_height = height;
 }
}

　　很显然输入的不是两个True，根本原因就在于正方形只有长的概念，而没有长方形所期望的宽的概念，所以长方形中定义了正方形根本没有的东西，也就是说长方形不应该是正方形的基类。

　　当一个基类出现了其子类不想要的接口成员时，继承关系必然是欠缺考虑的继承，也必然是违反LSP原则的。这个时候要么把想办法把基类的那个成员抽象出去，要么子类再选择从合适的基类继承。记住这个思路，在下一个原则我们还会再相见。

　　此外，当我在小孩玩橡皮鸭子的时候，常常在想：橡皮鸭子能从鸭子继承吗？你觉得呢？

 

接口分离原则(ISP)：不要一口吃成胖子

　　接口分离原则全称interface segregation principle，简称ISP，它的定义是：

不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。

　　这一原则与单一职责原则息息相关，它们对于高内聚的追求是一致的，但是它更加强调了接口的高内聚性。

　　看个例子，我们有一个服务接口，是这么定义的：

interface IService
{
 void GetUser();
 void RegisterUser();
 void LoadProducts();
 void AddProduct();
 void AcceptRequest();
 void SendResponse();
}

　　因为是面向所有Client的，所以这个接口提供了所有Client需要的方法，比如用户的操纵，产品的操作，数据传输的一些操作，每个Client都可能用到其中的一部分服务。

　　这个设计运行很好，服务端提供一个类Service实现这个接口，而Client，它通过某些网络服务方式获取到这个接口IService就可以了，然后直接调用相关方法就可以了。

　　先说第一点，这个接口违反了单一职责原则，一个字，"拆"。

　　再说第二点，每个类型的Client只处理一种对象，比如有的Client，如工资系统只处理User，而仓库系统只处理Product，接口的其它方法对它们没用，还是一个字，"拆"。

　　于是得到下列接口：

interface IUser
{
 void GetUser();
 void RegisterUser();
}
interface IProduct
{
 void LoadProducts();
 void AddProduct();
}
interface IPeer
{
 void AcceptRequest();
 void SendResponse();
}
class Service : IUser, IProduct, IPeer {}

　　这样拿到代理对象后，想处理用户的Client，将该对象转换成IUser即可，想处理产品的转换成IProduct即可。

　　同样的，试想一下，如果某一天某Service只提供有关用户的服务，在原先的设计中会怎么样？

 

依赖倒置原则(DIP)：抽象的艺术才有生命力

　　依赖倒置原则全称Dependence Inversion Principle，简称DIP，它的定义有3点含义：

1、高层模块不应该依赖低层模块，两者都应该依赖于抽象(抽象类或接口)
2、抽象(抽象类或接口)不应该依赖于细节(具体实现类)
3、细节(具体实现类)应该依赖抽象

　　总结起来，这个原则说的就是每个类与别的类交互时，尽量只使用满足接口规范的抽象类。为啥？因为抽象类实现细节几乎没有，没什么需要变化的。这一条深刻揭示了抽象的生命力，抽象的对象才是最有表达能力的对象，因为它通常是“无形”的，可以随时填充相关的细节。

　　直接看一个例子：

public class Program
{
 static void Main(string[] args)
 {
  UI layer = new UI();
  layer.SetDataAccessor(new XmlDataAccessor());
  layer.Do();
 }
}
 
class UI
{
 DataAccessor m_accessor;
 
 public void SetDataAccessor(DataAccessor accessor) { m_accessor = accessor; }
 public void Do()
 {
  m_accessor.GetUser();
 }
}
 
interface DataAccessor
{
 void GetUser();
 void RegisterUser();
}
 
class XmlDataAccessor : DataAccessor
{
 public void GetUser() { }
 public void RegisterUser() { }
}

　　这里上游的组件UI依赖的是DataAccessor这样的接口，而不是依赖各种具体的子类，如XmlDataAccessor，这样当想使用其他的数据库存储数据的时候，只要增加新的DatabaseDataAccessor之类的新类，然后在设置的时候设置一下就可以了。这种手段，很多人也称为"依赖注入"。

 

　　好了，核心原则说完了，总结一下，似乎就是一句话："类要单纯，继承要谨慎，变化要封装，抽象类型要多用"。