为了账号安全,请及时绑定邮箱和手机立即绑定

面向对象的六大设计原则(终结篇)

标签:
Java Android

四、接口隔离原则:Interface Segregation Principle(ISP)

定义:客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上。这个原则比较简单很好理解,但熟练使用却不简单。如何适度的使用接口,需要我们进行反复的思考与设计,才能很好的实践这一原则。这就好像我们的笔记本电脑,一般只会有USB、HDMI、VGA和网线接口。简简单单的几个接口,支持设备的接入,网络连接,视频投影。再多的话,就会造成接口冗余,少了的话, 又无法满足现实所需。

接下来我们看些Android中的一些源码

    public interface OnClickListener {
        /**
         * Called when a view has been clicked.
         *
         * @param v The view that was clicked.
         */
        void onClick(View v);
    }

    public interface OnLongClickListener {
        /**
         * Called when a view has been clicked and held.
         *
         * @param v The view that was clicked and held.
         *
         * @return true if the callback consumed the long click, false otherwise.
         */
        boolean onLongClick(View v);
    }

这是Android中我们经常使用的两个接口,分别用于用户监听点击事件和长按事件,同样都是点击事件,Android工程师为什么不把这两个接口合并在一起而要分开呢?这里Android工程师就很好的遵循了接口隔离原则。虽然两个接口的功能类似,都是处理用户的点击事件,但试想一下,如果Android工程师把这两个接口合并到一起,每当我们要单独处理一个点击事件的时候,都必须连带把另外一个接口也要实现,这就会造成大量无用的实现,造成大量无用冗余代码。

采用接口隔离原则对接口进行约束时,我们要让接口尽量小,但凡是都要有个度。细化的接口确实能极大的提高程序的灵活性,但过于细化接口,反而会造接口数量过多,反而使得程序难以维护,这就又背于我们的初衷了。至于这个度如何把握,需要我们在设计时,去反复推敲,反复思考,才能很好的践行这一职责。

五、迪米特原则:Law of Demeter(LOD)

定义:最少知道原则,一个对象应该对其他对象保持最少的了解。简单点说,一个类应该对自己需要调用或者耦合的类知道的越少越好,类的内部如何实现于调用者或者依赖着没关系,调用者只需要知道他需要调用的方法即可。类与类之间的关系越密切,耦合度也就越大,当类发生改变时,对另外一个类的影响也就越大。迪米特原则还有一个更简单的定义:只与直接的朋友通信。首先来解释一下什么是直接的朋友:每个对象都会与其他对象有耦合关系,只要两个对象之间有耦合关系,我们就说这两个对象之间是朋友关系。耦合的方式很多,依赖、关联、组合、聚合等。其中,我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友,而出现在局部变量中的类则不是直接的朋友。也就是说,陌生的类最好不要作为局部变量的形式出现在类的内部。

六、开闭原则:Open Close Principle(OCP)

在第一篇帖子中,已经讲到过开闭原则,先来看下当时的demo
不遵循开闭原则的代码

    public void analysisData(Mode type){
        if(type = xml){
            //进行xml 数据格式解析
        }else if(type = json){
            // 进行 json 数据格式解析
        }
    }
    public void analysisData(Mode type){
        if(type = xml){
            //进行xml 数据格式解析
        }else if(type = json){
            // 进行 json 数据格式解析
        }else if(type = 流文件){
            // 进行 数据流解析
        }else if(...type.) {
            //  
        }
    }

遵循开闭原则之后的代码

public class HttpUtils {

    AnalysisDate analysisData;

    public void analysisData(Mode type){
        analysisDate.analysis(type);
    }

    public void setAnalysisData(AnalysisData analysisDate){
        this.analysisDate = analysisDate;
    }

}    

/**
 * 解析数据接口
 *
 */
public interface  AnalysisData{
    void analysis(Mode type);
}

public class JsonAnalysisDate implements AnalysisData{

    public void analysis(Mode type) {
        // json 数据解析
    }
}
public class XmlAnalysisDate implements AnalysisData{

    public void analysis(Mode type) {
        // xml 数据解析
    }
}

仔细观察上面优化之后代码,发现基本上前面所讲的五种模式都涉及在里面了。在仔细思考以及仔细阅读很多设计模式的文章后,终于对开闭原则有了一点认识。其实,我们遵循设计模式前面5大原则,以及使用23种设计模式的目的就是遵循开闭原则。也就是说,只要我们对前面5项原则遵守的好了,设计出的软件自然是符合开闭原则的,这个开闭原则更像是前面五项原则遵守程度的“平均得分”,前面5项原则遵守的好,平均分自然就高,说明软件设计开闭原则遵守的好;如果前面5项原则遵守的不好,则说明开闭原则遵守的不好。

总结:在应用开发中,最难的不是开发出应用,而是在后续的升级维护中能让应用拥抱变化,能让应用在满足不断变化需求的同时,不破坏系统的稳定性。在经历了各个版本迭代之后让程序依然能够结构清晰、灵活、易于维护。

上面部分来自《Android源码与设计模式》和csdn各路大牛的博客和小鱼个人的见解,欢迎大家继续关注

点击查看更多内容
16人点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
JAVA开发工程师
手记
粉丝
8549
获赞与收藏
6550

关注作者,订阅最新文章

阅读免费教程

感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消