大话设计模式——六大原则(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)

待更新...

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,029评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,395评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,570评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,535评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,650评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,850评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,006评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,747评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,207评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,536评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,683评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,342评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,964评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,772评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,004评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,401评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,566评论 2 349

推荐阅读更多精彩内容

  • 目录: 设计模式六大原则(1):单一职责原则 设计模式六大原则(2):里氏替换原则 设计模式六大原则(3):依赖倒...
    加油小杜阅读 723评论 0 1
  • 设计模式六大原则 设计模式六大原则(1):单一职责原则 定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类...
    viva158阅读 765评论 0 1
  • 前言 设计模式六大原则网上资料比较多比较乱,本文将网上的一些好的资料做一下整理,以便随时翻阅。友情提示,设计模式虽...
    简单的土豆阅读 1,431评论 0 10
  • 设计模式之六大原则(转载) 关于设计模式的六大设计原则的资料网上很多...
    霄霄霄霄阅读 898评论 0 1
  • 整理总结自《设计模式之禅》一书 1 单一职责原则 Single Responsibility Principle ...
    笑哥哥阅读 439评论 0 1