五大设计原则
博客专区 > AustinYe 的博客 > 博客详情
五大设计原则
AustinYe 发表于3个月前
五大设计原则
  • 发表于 3个月前
  • 阅读 1
  • 收藏 0
  • 点赞 0
  • 评论 0

腾讯云 技术升级10大核心产品年终让利>>>   

摘要: 设计模式基础

单一职责模式

    如果一个类的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当发生变化时,设计会遭受到意想不到的破坏。
    软件设计真正要做得许多内容,就是发现职责并把这些职责相互分离
    如何判断?如果你能够想到多余一个的动机去改变一个类,那么这个类就具有多于一个的职责

开放封闭原则

     面对需求,对程序的改动是通过增加新代码进行得,而不是更改现有的代码
    软件实体(类、模块、函数等),应该是可以扩展,但是不可修改
        对于扩展是开放的(Open for extension)
        对于更改是封闭的(Closed for modification)
        怎样设计才能面对需求的改变却可以保持相对稳定,从而使得系统可以在第一个版本以后不断推出新的版本
    无论模块是多么的‘封闭’,都会存在一些无法对之封闭的变化。既然不可能完全封闭,设计人员必须对于他设计的模块应该对哪种变化封装做出选择。他必须先猜测(ps:业务预测,架构及模块设计,也是基于对业务发展得预判上的)出最有可能发生的变化种类,然后构造抽象来隔离那些变化,等到有细微变化时,立即采取行动。(当发生变化时,创建抽象来隔离以后发生的同类变化)

里氏替换原则

        子类型必须能够替换掉他们的父类型
        只有当子类可以替换吊父类,软件单位的功能不受影响时,父类才能真正被复用,而子类也能够在父类的基础上增加新的行为。

依赖倒转原则

            抽象不应该依赖细节,细节应该依赖抽象(面向抽象(接口)编程,不要面向实现编程)
            程序中所有的依赖关系都是终止于抽象类或者接口,      

迪米特法则

    迪米特法则也称最少知识原则,一个对象应该对其它对象有最少的了解。通俗也说:一个类应该对自己需要耦合或调用的类知道得最少

    隐藏内部实现及细节

       迪米特法则的做法观念就是类间解耦,弱耦合,只有弱耦合了以后,类的复用率才可以提高,其要求的结果就是产生了大量的中转或跳转类,导致的复杂性提高,同时也为维护带来了难度,所以在采用迪米特法则时需要反复权衡,既做到让结构清晰,又做到高内聚低耦合。

      但是过度使用迪米特法则,也会造成系统的不同模块之间的通信效率降低,使系统的不同模块之间不容易协调等缺点。同时,因为迪米特法则要求类与类之间尽量不直接通信,如果类之间需要通信就通过第三方转发的方式,这就直接导致了系统中存在大量的中介类,这些类存在的唯一原因是为了传递类与类之间的相互调用关系,这就毫无疑问的增加了系统的复杂度。解决这个问题的方式是:使用依赖倒转原则(通俗的讲就是要针对接口编程,不要针对具体编程), 这要就可以是调用方和被调用方之间有了一个抽象层,被调用方在遵循抽象层的前提下就可以自由的变化,此时抽象层成了调用方的朋友。
共有 人打赏支持
粉丝 0
博文 1
码字总数 1013
×
AustinYe
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: