大话设计模式——六大原则(SOLID)

S:单一职责原则(Single responsibility principle)

• **解释:**它规定一个类应该只有一个发生变化的原因。单一职责原则是最简单的面对对象设计原则，它用于控制类的粒度大小。在软件系统中，一个类（大到模块，小到方法）承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作，因此要将这些职责进行分离，将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中，如果多个职责总是同时发生改变则可将它们封装在同一类中。

• **优点:**类的职责变得单一，复杂度降低、可读性提高、可维护性提高、扩展性提高、降低了变更引起的风险。在<<大话设计模式>>第三章中的情景中，手机的职责较多，可以拍照、打电话、玩游戏等等，但是如果单论拍照手机比不过单反、玩游戏也比不过游戏机…所以，单一职责往往更加优秀，类能够职责分离，才能够更容易维护、扩展、复用…

• **栗子:**网上确实有一些例子，但总是感觉有点牵强，或者说不能说服我，大部分例子其实就是为了举例而举例，和实际开发有点脱节。这里贴一个网上常见例子:JAVA单一职责原则。当然，还是举一个我觉得不错的例子，在JavaWeb项目中，分包经常是分出model、service、dao等等，这里以用户登录注册功能举例。用户输入账户密码，提交验证数据库的用户表，或者提交注册信息，数据库进行保存，实现这个功能，一般需要以下类，每个类单独承担一个职责。UserDao只用于数据库用户的查询和保存，UserService用于校验来登录注册，User是实体对象。
  在实体对象层定义类User:

  public class User {  
      private String username;  
      private String userpass;   
      private int role; 
      //…………各个属性的get、set方法 
  }
  

  在业务逻辑层上定义类UserService

  public class UserService {  
      private UserDao userDao = new UserDao();  
      //验证用户名和密码   
      public boolean CheckUser(String name,String pass) {   
          boolean flag=false;   
          User user =userDao.getUserByName(name);   
          if(user!=null&&user.getUsername().equals(pass)) {      
              flag=true;      
          }    
          return flag;   
      }      
      //注册新用户   
      public void registUser(User user) {        
          if(userDao.getUserByName(user.getUsername()) !=null) {
              System.out.println("用户名已存在");    
              return;   
          }      
          if(UserDao.addUser(user)) { 
              //注册成功    
          }else {    
              //注册失败   
          }      
      }   
  } 
  

  在数据访问层定义类UserDao:

  public class UserDao extends BaseDao {  
      //返回所有用户  
      public List<User> getAllUser() {       
          List<User> userList = new ArrayList<User>();   
          ......
          //访问数据库    
          return userList;   
      }   
      //根据用户名查找用户   
      public User getUserByName(String name) {   
          User user=null;   
          String sql="SELECT * FROM userdetail WHERE username=?";    
          ...
          //查找相应用户名的用户    
          return user;  
      }   
      //添加新用户   
      public boolean addUser(User user) {    
          //返回true 表示成功   
      } 
  } 
  

O:开放封闭原则(Open Close Principle)

• **解释:**开闭，对扩展开放，对修改关闭。尽量通过扩展软件实体来解决需求变化，而不是通过修改已有的代码来完成变化。在开发软件的过程中，因为变化、升级和维护等原因需要对软件原有的代码进行修改，可能会将错误引入原本已经测试过的旧代码中，破坏原有的系统，因此，当软件需求变化时，我们应尽量运用扩展的方式来实现变化，而不是修改原来的代码。
• **优点:**开闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开闭原则可以说是一种软件设计的总纲， 一个软件产品在生命周期内，都会发生变化，既然变化是一个既定的事实，我们就应该在设计的时候尽量适应这些变化，以提高项目的稳定性和灵活性。开闭原则具有理想主义的色彩，它是面向对象设计的终极目标，其他原则可以认为是开闭原则的实现方法。
• **栗子:**在我们大话设计模式——简单工厂模式文章中(建议看一下)，计算器程序的设计一开始完全采用的是面向过程的思路，当我们需要增加其他运算时，我们必须对客户端代码进行修改，增加新的swith-case分支来实现需求的变化。这种方式就是修改，而我们采用工厂模式进行重构时，当需要进行新的运算时，仅仅需要新建运算类继承Operation抽象类，重写getResult()方法。具体代码参考文章原文，这里贴一下UML图便于理解。
  

L:迪米特法则(Law of Demeter)

• **解释:**迪米特法则又叫作最少知道原则(Least Knowledge Principle 简写LKP），就是说一个对象应当对其他对象有尽可能少的了解，不和陌生人说话。一个类对自己依赖的类知道的越少越好。自从我们接触编程开始，就知道了软件编程的总的原则：低耦合，高内聚。无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。

• **优点与缺点:**迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。迪米特法则不希望类之间建立直接的联系。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。

• **栗子:**门面模式和中介模式是迪米特法则的俩个典型设计模式。其实在大话设计模式——策略模式一文中，引入策略模式的好处体现在客户端代码里，简单工厂需要认识俩个类:Charge和ChargeFactory，而策略模式仅需要客户端认识ChargeContext一个类即可，耦合度更低，这就符合了迪米特法则。这里也再举一个网上简单的例子，我觉得一般，可以参考。迪米特有个重要法则，只和 朋友类 交流。什么是朋友类？出现在成员变量、方法的输入输出参数中的类称为成员朋友类，而出现在方法体内部的类不属于朋友类。
  老师类定义了一个方法，可以发号施令让队长(GroupLeader)数人头数，中间在方法的实现中，突然需要依赖Girl类，这就违反了迪米特法则。

  public class Teacher {
      public void commond(GroupLeader groupLeader) {
          List<Girl> listGirls = new ArrayList<Girl>();
          for (int i = 0; i < 20; i++) {
  	            listGirls.add(new Girl());
          }
          groupLeader.countGirls(listGirls);
      }
  }
  

  所以，我们进行重写，将添加20个Girl对象的事情在GroupLeader中去做。

  public class Teacher {
      public void commond(GroupLeader groupLeader) {
          groupLeader.countGirls();
      }
  }
  

  public class GroupLeader {
      private List<Girl> listGirls;
      public GroupLeader(List<Girl> _listGirls) {
          this.listGirls = _listGirls;
      }
  	  
      public void countGirls() {
          System.out.println("女生数量是：" + listGirls.size());
      }
  }
  

  这个例子怎么说呢，我觉得不好或者牵强的地方就是这20个Girl对象构造的有点别扭，正常实际开发时，都是从别处获取到的比如调用Xxx类的getAllGirls()方法来获得的，而我们的GroupLeader完全可以充当这个角色，所以自然而然代码就会写成遵从迪米特法则的形式。So，作为单纯讲解迪米特法则的栗子，我觉得还OK，但考虑到实际开发，我觉得有失公正…

L:里氏替换原则(Liskov Substitution Principle)

待更新…

I:接口隔离原则(Interface Segregation Principle)

待更新…

D:依赖倒置原则(Dependence Inversion Principle)

待更新…