违反这些设计原则，系统就等着“腐烂”-六虎

分享是最有效的学习办法。
_{博客：blog.ktdaddy.com/}

_{老猫的规划形式专栏现已偷偷发车了。不甘愿做crud boy？看了好几遍的规划形式还记不住？那就不要故意记了，跟上老猫的脚步，在一个个风趣的职场故事中领会规划形式的精髓吧。还等什么？赶忙上车吧}

故事

这段时刻以来，小猫依照之前的体系梳理计划【体系梳理大法&代码梳理大法】一向在整理着文档。

体系中涉及的事务以及模型也根本了然于胸，可是这代码写的真的是…

小猫也终于知道了为什么每天都有客诉，为什么每天都要去调用curl句子去订正出产的数据，为什么每天都在Hotfix…

整理了一下，大概出于这些原因，事务流程复杂暂且不议，光从技术视点来看，整个代码体系臃肿不堪，出问题之后定位困难，后边接手的几任开发为了处理问题都是“曲线救国”，不从正面去处理问题，为了处理一时的客诉问题而去处理问题，所以界说了各种新的修复流程去处理问题，这么一来，软件体系“无序”总量一向在添加，整个体系体系其实在初版之后就现已在“腐朽”了，如此？且抛开运维稳定性不谈，就体系本身稳定性而言，能好？

所以那两次事端还真不能怪小猫【事端1,事端2】

整个体系，除了堆事务仍是堆事务，但凡有点软件规划准则，体系也不会写成这样了。

关于规划准则

咱们在产品提出需求之后，一般都会去规划数据模型，还有体系流程。可是各位有没有深度去规划一下代码的完成呢？仍是说上手就直接照着流程图开始撸事务了？估计有许多的小伙伴由于各种原因不会去考虑代码规划，其实老猫许多时分也相同。主要原因比方：项目催的紧，哪有时刻考虑那么多，功用先做出来，剩余的等到后边渐渐优化。可是跟着时刻的推移，咱们会发现咱们一向很忙，说好的把曾经的代码重构好一点，哪有时刻！所以，就这样“技术债”越来越多，就像滚雪球相同，整个体系逐渐“腐朽”到了根。终究坑的或许是自己，也有或许是“下一个他”。

虽然在日常开发的时分项目进度比较严重，咱们许多时分也不去深度规划代码完成，可是咱们在写代码的时分保证心中有一杆秤其实仍是必要的。

那咱们就结合各种案来聊聊“这杆秤”————软件规划准则。

下面咱们经过各种小比如来协助咱们了解软件规划准则，事例是老猫设想的，有的时分不要过分较真，主要意图是讲清楚准则。别的后文中也会有相关的类图表示实体之间的关系，假如咱们对类图不太熟悉的，也能够看一下这里【类图传送门】

开闭准则

开闭准则，英文(Open-Closed Principle,简称：OCP)。只要指一个软件实体（例如，类，模块和函数），应该对扩展开放，对修正封闭。其重点着重的是笼统构建结构，完成扩展细节，然后提升软件体系的可复用性以及可保护性。

概念是笼统，可是事例是详细的，所以咱们直接看事例，经过事例去了解或许更简单。

由于小猫最近在保护商城类事务，所以咱们就从产品折价售卖这个事例动身。事务是这样的，商城需求对产品进行做打折活动，现在针对不同品类的产品或许打折的力度不相同，例如生活用品和汽车用品的打折情况不同。创立一个根底产品接口：

public interface IProduct {
    String getSpuCode(); //获取产品编号
    String getSpuName(); //获取产品称号
    BigDecimal getPrice(); //获取产品价格
}

根底产品完成该接口,所以咱们就有了如下代码：

/**
 * @Author: 公众号：程序员老猫
 * @Date: 2024/2/7 23:39
 */
public class Product implements IProduct {
    private String spuCode;
    private String spuName;
    private BigDecimal price;
    private Integer categoryTag;
    public Product(String spuCode, String spuName, BigDecimal price, Integer categoryTag) {
        this.spuCode = spuCode;
        this.spuName = spuName;
        this.price = price;
        this.categoryTag = categoryTag;
    }
    public Integer getCategoryTag() {
        return categoryTag;
    }
    @Override
    public String getSpuCode() {
        return spuCode;
    }
    @Override
    public String getSpuName() {
        return spuName;
    }
    @Override
    public BigDecimal getPrice() {
        return price;
    }
}

依照上面的事务，现在搞活动，咱们需求针对不同品类的产品进行促销活动，例如生活用品需求进行折扣。当然咱们有两种办法完成这个功用，假如咱们不改变原有代码，咱们能够如下完成。

public class DailyDiscountProduct extends Product {
    private static final BigDecimal daily_discount_factor = new BigDecimal(0.95);
    private static final Integer DAILY_PRODUCT = 1;
    public DailyDiscountProduct(String spuCode, String spuName, BigDecimal price) {
        super(spuCode, spuName, price, DAILY_PRODUCT);
    }
    public BigDecimal getOriginPrice() {
        return super.getPrice();
    }
    @Override
    public BigDecimal getPrice() {
        return super.getPrice().multiply(daily_discount_factor);
    }
}

上面咱们看到直接打折的日常用品的产品承继了规范产品，并且对其进行了价格重写，这样就完成了生活用品的打折。当然这种打折系数的话咱们一般能够装备到数据库中。

对汽车用品的打折其实也是相同的完成。承继之后重写价格即可。咱们并不需求去根底产品Product中依据不同的品类去更改产品的价格。

过错事例，

假如咱们一味地在原始类别上去做逻辑应该便是如下这样：


public class Product implements IProduct {
    private static final Integer DAILY_PRODUCT = 1;
    private static final BigDecimal daily_discount_factor = new BigDecimal(0.95);
    private String spuCode;
    private String spuName;
    private BigDecimal price;
    private Integer categoryTag;
    ....
    @Override
    public BigDecimal getPrice() {
      if(categotyTag.equals(DAILY_PRODUCT)){
        return price.multiply(daily_discount_factor);
      }
      return price;
    }
}

后续跟着事务的演化，后边假如提出对产品称号也要定制，那么咱们或许仍是会动当时的代码，咱们一向在改当时类，代码越堆越多，越来越臃肿，这种完成办法就破坏了开闭准则。

咱们看一下开闭准则的类图。如下：

依靠倒置准则

依靠倒置准则，英文名(Dependence Inversion Principle,简称DIP)，指的是高层模块不应该依靠低层模块，二者都应该依靠其笼统。经过依靠倒置，能够减少类和类之间的耦合性，然后进步体系的稳定性。这里主要着重的是，咱们写代码要面向接口编程，不要面向完成去编程。

界说看起来不行详细，咱们来看一下下面这样一个事务。针对不同的大客户，咱们定制了许多商城，有些商城是专门售卖电器的，有些商城是专门售卖生活用品的。有个大客，由于对方是电器供货商，所以他们想售卖自己的电器设备，所以，咱们就有了下面的事务。

//界说了一个电器设备商城，并且支撑特有的电器设备下单流程
public class ElectricalShop {
    public String doOrder(){
        return "电器商城下单";
    }
}
//用户进行下单购买电器设备
public class Consumer extends ElectricalShop {
    public void shopping() {
        super.doOrder();
    }
}

咱们看到，当客户可选择的只有一种商城的时分，这种完成办法的确如同没有什么问题，可是现在需求变了，立刻要春节了，大客户不想只是给他们的客户供给电器设备，他们还想卖海鲜产品，这样，曾经的这种下单形式如同会有点问题，由于曾经咱们直接承继了ElectricalShop，这样写的话，事务可拓展性就太差了，所以咱们就需求笼统出一个接口，然后客户在下单的时分能够选择不同的商城进行下单。所以改造之后，咱们就有了如下代码：

//笼统出一个更高维度的商城接口
public interface Shop {
    String doOrder();
}
//电器商城完成该接口完成自有下单流程
public class ElectricalShop implements Shop {
    public String doOrder(){
        return "电器商城下单";
    }
}
//海鲜商城完成该接口完成自有下单流程
public class SeaFoodShop implements Shop{
    @Override
    public String doOrder() {
        return "售卖一些海鲜产品";
    }
}
//顾客注入不同的商城产品信息
public class Consumer {
    private Shop shop;
    public Consumer(Shop shop) {
        this.shop = shop;
    }
    public String shopping() {
        return shop.doOrder();
    }
}
//顾客在不同商城随意切换下单测验
public class ConsumerTest {
    public static void main(String[] args) {
        //电器商城下单
        Consumer consumer = new Consumer(new ElectricalShop());
        System.out.println(consumer.shopping());
        //海鲜商城下单
        Consumer consumer2 = new Consumer(new SeaFoodShop());
        System.out.println(consumer2.shopping());
    }
}

上面这样改造之后，本来承继详细商城完成的Consumer类，现在直接将更高维度的商城接口注入到了类中，这样信任后边再多几个新的商城的下单流程都能够很方便地就完成拓展。

这其实也便是依靠倒置准则带来的优点，咱们终究来看一下类图。

单一责任准则

单一责任准则，英文名(SimpleResponsibility Pinciple,简称SRP)指的是不要存在剩余一个导致类改变的原因。这句话看起来仍是比较笼统的，老猫个人的了解是单一责任准则重点是区分事务鸿沟，做到合理地区分事务，依据产品的需求不断去从头规划规划当时的类信息。关于单一责任老猫其实之前现已和咱们分享过了,在此不多赘述，咱们能够进入这个传送门【单一责任准则】

接口阻隔准则

接口阻隔准则（Interface Segregation Principle,简称ISP）指的是指尽量供给专门的接口，而非运用一个混合的复杂接口对外供给服务。

聊到接口阻隔准则，其实这种准则和单一责任准则有点类似，可是又不同：

联络：接口阻隔准则和单一责任准则都是为了进步代码的可保护性和可拓展性以及可重用性，其中心的思维都是“高内聚低耦合”。
区别：针对性不同，接口阻隔准则针对的是接口，而单一责任准则针对的是类。

下面，咱们用一个事务比如来阐明一下吧。咱们用简单的动物行为这样一个比如来阐明一下，动物从大的方面有能飞的，能吃，能跑，有的也会游水等等。假如咱们界说一个比较大的接口便是这样的。

public interface IAnimal {
    void eat();
    void fly();
    void swim();
    void run();
    ...
}

咱们用猫咪完成了该办法，所以就有了。

public class Cat implements IAnimal{
    @Override
    public void eat() {
        System.out.println("老猫喜欢吃小鱼干");
    }
    @Override
    public void fly() {
    }
    @Override
    public void swim() {
    }
    @Override
    public void run() {
        System.out.println("老猫还喜欢奔驰");
    }
}

咱们很简单就能发现，假如老猫不是“超人猫”的话，老猫就没办法飞翔以及游水，所以当时的类就有两个空着的办法。相同的假如有一只百灵鸟，那么完成Animal接口之后，百灵鸟的游水办法也是空着的。那么这种完成咱们发现只会让代码变得很臃肿，所以，咱们发现IAnimal这个接口的界说太大了，咱们需求依据不同的行为进行二次拆分。拆分之后的成果如下：

//一切的动物都会吃东西
public interface IAnimal {
    void eat();
}
//专心飞翔的接口
public interface IFlyAnimal {
    void fly();
}
//专心游水的接口
public interface ISwimAnimal {
    void swim();
}

那假如现在有一只鸭子和百灵鸟，咱们分别去完成的时分如下：

public class Duck implements IAnimal,ISwimAnimal{
    @Override
    public void eat() {
        System.out.println("鸭子吃食");
    }
    @Override
    public void swim() {
        System.out.println("鸭子在河里游水");
    }
}
public class Lark implements IAnimal,IFlyAnimal{
    @Override
    public void eat() {
        System.out.println("百灵鸟吃食");
    }
    @Override
    public void fly() {
        System.out.println("百灵鸟会飞");
    }
}

咱们能够看到，这样在咱们详细的完成类中就不会存在空办法的情况，代码跟着事务的发展也不会变得过于臃肿。咱们看一下终究的类图。

迪米特准则

迪米特准则（Law of Demeter,简称 LoD）,指的是一个对象应该对其他对象坚持最少的了解，假如上面这个准则称号不简单记，其实这种规划准则还有两外一个称号，叫做最少知道准则（Least Knowledge Principle,简称LKP）。其实主要着重的也是下降类和类之间的耦合度，白话“不要和陌生人说话”，或许也能够了解成“让专业的人去做专业的工作”，出现在成员变量，办法输入、输出参数中的类都能够称为成员朋友类，而出现在办法体内部的类不属于朋友类。

经过详细场景的比如来看一下。由于小猫接手了商城类的事务，现在他对事务的完成细节应该是最清楚的，所以领导在向老板报告相关SKU出售情况的时分总是会找到小猫去核算各个品类的sku的出售额以及出售量。所以就有了领导下命令，小猫去做核算的事务流程。

//sku产品
public class Sku {
    private BigDecimal price;
    public BigDecimal getPrice() {
        return price;
    }
    public void setPrice(BigDecimal price) {
        this.price = price;
    }
}
//小猫核算总sku数量以及总出售金额
public class Kitty {
    public void doSkuCheck(List<Sku> skuList) {
        BigDecimal totalSaleAmount =
                skuList.stream().map(sku -> sku.getPrice()).reduce(BigDecimal::add).get();
        System.out.println("总sku数量：" + skuList.size() + "sku总出售金额：" + totalSaleAmount);
    }
}
//领导让小猫去核算各个品类的产品
public class Leader {
    public void checkSku(Kitty kitty) {
        //模拟领导指定的各个品类
        List<Sku> difCategorySkuList = new ArrayList<>();
        kitty.doSkuCheck(difCategorySkuList);
    }
}
//测验类
public class LodTest {
    public static void main(String[] args) {
        Leader leader = new Leader();
        Kitty kitty = new Kitty();
        leader.checkSku(kitty);
    }
}

从上面的比如来看，领导其实并没有参加核算的任何工作，他只是指定了品类让小猫去核算。然后下降了类和类之间的耦合。即“让专门的人做专门的事”

咱们看一下终究的类图。

里氏替换准则

里氏替换准则(Liskov Substitution Principle,英文简称：LSP)，它由芭芭拉利斯科夫（Barbara Liskov）在1988年提出。里氏替换准则的意义是：假如一个程序中一切运用基类的地方都能够用其子类来替换，而程序的行为没有发生变化，那么这个子类就遵守了里氏替换准则。换句话说，一个子类应该能够彻底替代它的父类，并且坚持程序的正确性和一致性。

上述的界说仍是比较笼统的，老猫试着从头了解一下，

子类能够完成父类的笼统办法，可是不能掩盖父类的笼统办法。
子类能够添加自己特有的办法。
当子类的办法重载父类的办法的时，办法的前置条件（即办法的输入/入参）要比父类办法的输入参数愈加宽松。
当子类的办法完成父类的办法时，办法的后置条件比父类更严格或许和父类相同。

里氏替换准则准确来说是上述提到的开闭准则的完成办法，可是它克服了承继中重写父类造成的可复用性变差的缺陷。它是动作正确性的保证。即类的扩展不会给已有的体系引进新的过错，下降了代码犯错的或许性。

下面咱们用里式替换准则比较经典的比如来阐明“鸵鸟不是鸟”。咱们看一下咱们印象中的鸟类：

class Bird {
    double flySpeed; 
    //设置飞翔速度
    public void setSpeed(double speed) {
        flySpeed = speed;
    }
    //核算飞翔所需求的时刻
    public double getFlyTime(double distance) {
        return (distance / flySpeed);
    }
}
//燕子
public class Swallow extends Bird{
}
//由于鸵鸟不能飞，所以咱们将鸵鸟的速度设置为0
public class Ostrich extends Bird {
    public void setSpeed(double speed) {
        flySpeed = 0;
    }
}

光看这个完成的时分如同没有问题，可是咱们调用其办法核算其指定间隔飞翔时刻的时分，那么这个时分就有问题了，如下：

public class TestMain {
    public static void main(String[] args) {
        double distance = 120;
        Ostrich ostrich = new Ostrich();
        System.out.println(ostrich.getFlyTime(distance));
        Swallow swallow = new Swallow();
        swallow.setSpeed(30);
        System.out.println(swallow.getFlyTime(distance));
    }
}

成果输出：

Infinity
4.0

明显鸵鸟出问题了，

鸵鸟重写了鸟类的 setSpeed(double speed) 办法，这违背了里氏替换准则。
燕子和鸵鸟都是鸟类，可是父类抽取的共性有问题，鸵鸟的飞翔不是正常鸟类的功用，需求特别处理，应该抽取愈加共性的功用。

所以咱们进行对其进行优化，咱们撤销鸵鸟原来的承继关系，界说鸟和鸵鸟的更一般的父类，如动物类，它们都有奔驰的能力。鸵鸟的飞翔速度虽然为 0，但奔驰速度不为 0，能够核算出其奔驰指定间隔所要花费的时刻。优化之后代码如下：

//笼统出更高层次的动物类，界说内部的奔驰行为
public class Animal {
    double runSpeed;
    //设置奔驰速度
    public void setSpeed(double speed) {
        runSpeed = speed;
    }
    //核算奔驰所需求的时刻
    public double getRunTime(double distance) {
        return (distance / runSpeed);
    }
}
//界说飞翔的鸟类
public class Bird extends Animal {
    double flySpeed;
    //设置飞翔速度
    public void setSpeed(double speed) {
        flySpeed = speed;
    }
    //核算飞翔所需求的时刻
    public double getFlyTime(double distance) {
        return (distance / flySpeed);
    }
}
//此时鸵鸟直接承继动物接口
public class Ostrich extends Animal {
}
//燕子承继普通的鸟类接口
public class Swallow extends Bird {
}

简单测验一下：

public class TestMain {
    public static void main(String[] args) {
        double distance = 120;
        Ostrich ostrich = new Ostrich();
        ostrich.setSpeed(40);
        System.out.println(ostrich.getRunTime(distance));
        Swallow swallow = new Swallow();
        swallow.setSpeed(30);
        System.out.println(swallow.getFlyTime(distance));
    }
}

成果输出：

3.0
4.0

优化之后，优点：

代码共享，减少创立类的工作量，每个子类都具有父类的办法和特点；
进步代码的重用性；
进步代码的可扩展性；
进步产品或项意图开放性；

缺陷：

承继是侵入性的。只要承继，就有必要具有父类的一切特点和办法；
下降代码的灵敏性。子类有必要具有父类的特点和办法，让子类自由的国际中多了些约束；
增强了耦合性。当父类的常量、变量和办法被修正时，需求考虑子类的修正，并且在缺乏规范的环境下，这种修正或许带来非常糟糕的成果————大段的代码需求重构。

终究咱们看一下类图：

老猫觉得里氏替换准则是最难掌握好的，所以到后续咱们再进行深化涉及形式回归的时分再做深化探究。

组成复用准则

组成复用准则(Composite/Aggregate Reuse Principle,英文简称CARP)是指咱们尽量要运用对象组合而不是承继关系达到软件复用的意图。这样的话体系就能够变得愈加灵敏，一起也下降了类和类之间的耦合度。

看个比如，当咱们刚学java的时分都是从jdbc开始学起来的。所以对于DBConnection咱们并不陌生。那当咱们完成根本产品Dao层的时分，咱们就有了如下写法：

public class DBConnection {
    public String getConnection(){
        return "获取数据库链接";
    }
}
//根底产品dao层
public class ProductDao {
    private DBConnection dbConnection;
    public ProductDao(DBConnection dbConnection) {
        this.dbConnection = dbConnection;
    }
    public void saveProduct(){
        String conn = dbConnection.getConnection();
        System.out.println("运用"+conn+"新增产品");
    }
}

上述便是最简单的组成服用准则使用场景。可是这里有个问题，DBConnection现在只支撑mysql一种衔接DB的办法，明显不合理，有许多企业其实还需求支撑Oracle数据库链接，所以为了符合之前提到的开闭准则，咱们让DBConnection交给子类去完成。所以咱们能够将其界说成笼统办法。

public abstract class DBConnection {
    public abstract String getConnection();
}
//mysql链接
public class MySqlConnection extends DBConnection{
    @Override
    public String getConnection() {
        return "获取mysql链接";
    }
}
//oracle链接
public class OracleConnection extends DBConnection{
    @Override
    public String getConnection() {
        return "获取Oracle链接办法";
    }
}

终究的完成办法咱们一起看一下类图。

总结

之前看过一个故事，一栋楼的破落往往从一扇破窗户开始，渐渐腐朽。其实代码的腐朽其实也是相同，往往是一段拓展性极差的代码开始。所以这要求咱们研制人员仍是得心中有杆“规划准则”的秤，咱们或许不会去做故意的代码规划，可是信任有这么一杆准则的秤，代码也不致于会写得太烂。

当然咱们也不要故意去追求规划准则，要权衡详细的场景做出合理的取舍。规划准则是规划形式的根底，信任咱们在了解完规划准则之后对后续的规划形式会有愈加深刻的了解。

违反这些设计原则，系统就等着“腐烂”

故事

关于规划准则

开闭准则

依靠倒置准则

单一责任准则

接口阻隔准则

迪米特准则

里氏替换准则

组成复用准则

总结

相关文章

基于Seata探寻分布式事务的实现方案

【刷题笔记】1046. 最后一块石头的重量

Kafka 架构、核心机制和场景解读

Flutter 小技巧之 3.10 适配之单例 Window 弃用，一起来了解 View.of 和 PlatformDispatcher

作者信息