• 设计模式七大原则


    1.单一职责原则
    就一个类而言,应该只有一个引起它变化的原因。如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会影响到其他的职责,另外,把多个职责耦合在一起,也会影响复用性。
    2.
    开闭原则(Open-Closed Principle)
    开闭原则即OCP(Open-Closed Principle缩写)原则,该原则强调的是:一个软件实体(指的类、函数、模块等)应该对扩展开放,对修改关闭。即每次发生变化时,要通过添加新的代码来增强现有类型的行为,而不是修改原有的代码。 

    符合开闭原则的最好方式是提供一个固有的接口,然后让所有可能发生变化的类实现该接口,让固定的接口与相关对象进行交互。

     3. 里氏代替原则(Liskov Substitution Principle)

     Liskov Substitution Principle,LSP(里氏代替原则)指的是子类必须替换掉它们的父类型。也就是说,在软件开发过程中,子类替换父类后,程序的行为是一样的。只有当子类替换掉父类后,此时软件的功能不受影响时,父类才能真正地被复用,而子类也可以在父类的基础上添加新的行为。

     4. 依赖倒转原则

    依赖倒置(Dependence Inversion Principle, DIP)原则指的是抽象不应该依赖于细节,细节应该依赖于抽象,也就是提出的 “面向接口编程,而不是面向实现编程”。这样可以降低客户与具体实现的耦合。

     5. 接口隔离原则

    接口隔离原则(Interface Segregation Principle, ISP)指的是使用多个专门的接口比使用单一的总接口要好。也就是说不要让一个单一的接口承担过多的职责,而应把每个职责分离到多个专门的接口中,进行接口分离。过于臃肿的接口是对接口的一种污染。 
     6. 合成复用原则

    合成复用原则(Composite Reuse Principle, CRP)就是在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分。新对象通过向这些对象的委派达到复用已用功能的目的。简单地说,就是要尽量使用合成/聚合,尽量不要使用继承。 
    要使用好合成复用原则,首先需要区分”Has—A”和“Is—A”的关系。 
    “Is—A”是指一个类是另一个类的“一种”,是属于的关系,而“Has—A”则不同,它表示某一个角色具有某一项责任。导致错误的使用继承而不是聚合的常见的原因是错误地把“Has—A”当成“Is—A”.例如:

    这里写图片描述

    实际上,雇员、经历、学生描述的是一种角色,比如一个人是“经理”必然是“雇员”。在上面的设计中,一个人无法同时拥有多个角色,是“雇员”就不能再是“学生”了,这显然不合理,因为现在很多在职研究生,即使雇员也是学生。 
    上面的设计的错误源于把“角色”的等级结构与“人”的等级结构混淆起来了,误把“Has—A”当作”Is—A”。具体的解决方法就是抽象出一个角色类:

    这里写图片描述 
     7. 迪米特法则 
    迪米特法则(Law of Demeter,LoD)又叫最少知识原则(Least Knowledge Principle,LKP),指的是一个对象应当对其他对象有尽可能少的了解。也就是说,一个模块或对象应尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立,这样当一个模块修改时,影响的模块就会越少,扩展起来更加容易。 

  • 相关阅读:
    获取指定函数的函数名称(用于兼容IE)
    opa gatekeeper笔记:AdmissionReview input.request请求对象结构
    团队内部密码共享方案:KeePassXC+微盘(企业微信)
    一个简单的golang项目,实验 gitlab-ci-cd Pipelines
    调用企业微信API拨打紧急通知电话
    使用PAM模块实现普通用户之间su免密切换
    thin_check命令 man手册
    Nginx server_name翻译
    UDP端口检查告警SHELL脚本(企业微信版机器人版)
    从零搭建vsftpd
  • 原文地址:https://www.cnblogs.com/weixinyu98/p/9664862.html
Copyright © 2020-2023  润新知