聊聊软件设计原则

待兔 等级 551 0 0

软件设计知识是一名软件开发人员必须要懂的知识,最近几天今天看了bob大叔的《敏捷软件开发》一书和软件设计相关的一些blog和资料,自己做了一个学习笔记

设计目标

正确性、健壮性、灵活性、可重用性、高效性

降低复杂性

  • 所谓复杂性,就是任何使得软件难于理解和修改的因素。

  • 复杂性的来源主要有两个:代码的含义模糊和互相依赖

    • 模糊指的是,代码里的重要信息看不出来;
    • 依赖指的是,某个模块的代码,不结合其他模块的代码,就无法理解
  • 危害:复杂性的危害在于,它会递增。如果做错了一个决定,导致后面的代码都基于前面的错误实现,只会越来越复杂。"常听人说,我们先把产品做出来,后面再改进",这很难做到

  • ==关键==:找出易变化的部分,合理抽象。
    用抽象构建框架、用实现扩展细节

代码抽象三原则:

1. Don’t Repeat Yourself (DRY)

  • 系统的每一个功能都应该有唯一的实现。也就是说,如果多次遇到同样的问题,就应该抽象出一个共同的解决方法,不要重复开发同样的功能
    不要重复自己

2. You Ain’t Gonna Need It (YAGNI)

  • 定义:你不会需要它,只考虑和设计必须的功能,避免过度设计
  • 这是"极限编程"提倡的原则,指的是你自以为有用的功能,实际上都是用不到的。因此,除了最核心的功能,其他功能一概不要部署,这样可以大大加快开发
  • 你会发现DRY原则和YAGNI原则并非完全兼容。前者追求"抽象化",要求找到通用的解决方法;后者追求"快和省"

3.Rule Of Three

  • 称为"三次原则",指的是当某个功能第三次出现时,才进行"抽象化"。

  • 这样做有几个理由:

    • 省事。如果一种功能只有一到两个地方会用到,就不需要在"抽象化"上面耗费时间了。

    • 容易发现模式。"抽象化"需要找到问题的模式,问题出现的场合越多,就越容易看出模式,从而可以更准确地"抽象化"。

    • 防止过度冗余。如果一种功能同时有多个实现,管理起来非常麻烦,修改的时候需要修改多处。在实际工作中,重复实现最多可以容忍出现一次,再多就无法接受了。

  • 小结:综上所述,"三次原则"是DRY原则和YAGNI原则的折衷,是代码冗余和开发成本的平衡点,值得我们在"抽象化"时遵循

面向对象的S.O.L.I.D原则

1. SRP职责单一原则

  • 核心思想是一个类只做一件事,把事情做好,其只有一个引起它变化的原因,职责过多,引起它变化的原因就越多,将导致责任依赖增加耦合性
  • 遵循单一职责原的优点有:
    • 可以降低类的复杂度,一个类只负责一项职责,其逻辑肯定要比负责多项职责简单的多;
    • 提高类的可读性,提高系统的可维护性;
    • 变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。
  • 应用场景:迭代器

2. 里氏替换原则

  • 定义:所有引用基类的地方必须能透明地使用其子类的对象,替换之后,代码还能正常工作。它是使代码符合开闭原则的重要保证.
  • 问题:有一功能P1,由类A完成。现需要将功能P1进行扩展,扩展后的功能为P,其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成,则子类B在完成新功能P2的同时,有可能会导致原有功能P1发生故障
  • 解决:当使用继承时,遵循里氏替换原则。类B继承类A时,除添加新的方法完成新增功能P2外,尽量不要重写父类A的方法,也尽量不要重载父类A的方法
  • 换个说法是,子类可以扩展父类的功能,但不能改变父类原有的功能(不能破坏继承体系)
    1. 子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法
    2. 子类中可以增加自己特有的方法
    3. 当子类的方法重载父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更宽松。
    4. 当子类的方法实现父类的抽象方法时,方法的后置条件(即方法的返回值)要比父类更严格

3. 接口隔离原则

  • 定义:客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上。
  • 规约:建立单一接口,不要建立庞大臃肿的接口,尽量细化接口,接口中的方法尽量少,但不要过度。也就是说,我们要为各个类建立专用的接口,而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。接口是设计时对外部设定的“契约”,通过分散定义多个接口,可以预防外来变更的扩散,提高系统的灵活性和可维护性。
  • 示例:人们对电脑有不同的使用方式:如上网、看电影、写文档、玩游戏、通讯、计算和存储等.如果都把这些功能都定义在电脑的抽象类里面。那各种功能类型的电脑(如上网本、服务器、PC、智能学习机)都要现实这些接口。所以,应该把这些接口隔离开,这样不同功能的电脑只需要实现自己需要的接口.

接口隔离2.jpg

接口隔离1.jpg

4. 依赖倒置原则

  • 定义:高层模块不应该依赖底层模块的实现,而是依赖高层抽象。而且,二者都应该依赖于抽象。抽象不应该依赖细节;细节应该依赖抽象
  • 问题:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成。这种场景下,类A一般是高层模块,负责复杂的业务逻辑;类B和类C是低层模块,负责基本的原子操作;假如修改类A,会给程序带来不必要的风险
  • 解决:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率
  • 核心思想:面向接口编程,在java中,抽象指的是接口或者抽象类,细节就是具体的实现类,使用接口或者抽象类的目的是制定好规范和契约,而不去涉及任何具体的操作,把展现细节的任务交给他们的实现类去完成。
  • 好处:可以降低类之间的耦合性,提高系统的稳定性,降低修改程序造成的风险。
  • 应用模式:工厂模式
  • 规范:实际编程中,最好做到如下3点:
    1. 低层模块尽量都要有抽象类或接口,或者两者都有。
    2. 变量的声明类型尽量是抽象类或接口。
    3. 使用继承时遵循里氏替换原则

如果依赖的是一个稳定的具体类,那么可以直接依赖它

  • 层次化
    • 方式1:高层模块依赖底层实现模块,这种依赖性是传递的
    依赖倒置1.png
  • 方式2
    - 解除传递依赖关系
    - 接口所有权倒置:客户拥有抽象接口,它的服务者从这些抽象接口中派生,底层模块实现了在高层模块声明并被高层模块调用的接口
依赖倒置2.png

5. 开放/封闭原则

  • 对扩展开放,对修改关闭。如果有新的需求和变化可以对现有代码进行扩展,以适应新的情况.而不是对原有代码进行修改.
  • 解决:关键在于抽象、预测和刺激变化
  • 应用模式:装饰者模式(如java.io包),不改变原有代码扩展对象的行为

其他原则

1. Keep it sample,stupid(Kiss)

  • 保持简单、直接,不要复杂化
  • 模块分成接口和实现。接口要简单,实现可以复杂。
  • 好的 class 应该是"小接口,大功能",大量的功能隐藏在简单接口之下,对用户不可见,用户感觉不到这是一个复杂的 class.比如Unix 的文件读写接口

2. Program to an interface, not an implementation

  • 面向接口编程,而不是实现
  • 工厂模式、策略模式等等

3. 高内聚低耦合

  • 将模块间的耦合降到最低,努力让一个模块做到精益求精.内聚意味着独立和重用,耦合意味着多米诺骨牌效应.

4. 迪米特法则

又称最少知识原则,该原则告诉我们要降低耦合。

  • 定义:一个对象应该对其他对象保持最少的了解

  • 问题:类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大。

  • 解决:尽量降低类与类之间的耦合

  • 对于对象 ‘O’ 中一个方法’M’,M 应该只能够访问以下对象中的方法:

    • 对象O本身
    • 参数对象
    • 与对象O直接相关的对象
    • 方法中创建或实例化的对象
  • 应用模式:外观模式,提供一个统一的接口来访问子系统中的一群接口。外观定义了一个高层接口,让系统更容易使用

5. 好莱坞原则

  • 你不要找我,我会找你 。 高层组件对待底层组件的方式:别调用我们,我们会调用你
  • 应用场景:
    • 观察者模式,以通知替代轮询
    • 工厂模式
    • Ioc依赖注入,DI控制反转设计的基础,所有组件都是被动的,初始化和调用都由容器负责
    • 模板模式

6. 无环依赖原则

  • 包、服务之间的依赖结构必须是一个直接的无环图形,不能出现循环依赖
  • 打破循环依赖关系,解决关系耦合问题:
    • 使用依赖倒置原则和接口隔离原则
    • 创建新的包,将共同类抽象出来放在新的包里

7. 减少抛异常

  • 除了那些必须告诉用户的错误,其他错误尽量在软件内部处理掉,不要抛出

总结

  • 如何去遵守这些原则。对这些原则的遵守并不是是和否的问题,而是多和少的问题,也就是说,我们一般不会说有没有遵守,而是说遵守程度的多少。任何事都是过犹不及,设计模式的六个设计原则也是一样,制定这六个原则的目的并不是要我们刻板的遵守他们,而需要根据实际情况灵活运用。对他们的遵守程度只要在一个合理的范围内,就算是良好的设计。
收藏
评论区

相关推荐