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)
待更新...