软件设计的六大原则(设计模式前置知识)

目录

 一、开闭原则

二、里氏代换原则

三、依赖倒转原则

四、接口隔离原则

五、迪米特法则

六、合成复用原则

前言:在软件开发中,为了提高软件系统的可维护性和可复用性,增加软件的可扩展性和灵活性,程序员要尽量根据6条原则来开发程序,从而提高软件开发效率、节约软件开发成本和维护成本。

 一、开闭原则

        开闭原则:“对扩展开放,对修改关闭”。意思是对于我们平时写代码时,如果要给某个功能扩展一些东西,最好不要去修改原代码,而是去基于原代码的基础上进行扩展。什么意思呢,这里我们拿大家平时最喜欢玩的“王者荣耀”来举个例子,比如公孙离最近新出了一个皮肤,如果你是程序员,你会直接去在公孙离写好的代码上修改吗?不会吧!因为原代码已经是经过测试,能够很好的运行了,如果我们去修改原代码,可能会引起一些不必要的麻烦。因此这里就需要我们当时对“公孙离”这个英雄类的皮肤那部分代码利用“开闭原则”的思想设计,以下我们用代码来简单解释一下。

public class GongSunLi { //公孙离类
    public int state; //状态为0是原皮  1是伴生皮
    public void currentSkin(){
        if(state==0) System.out.println("当前使用原皮");
        else if(state==1) System.out.println("当前使用伴生皮");
    }
}

可见,上述是我们不使用开闭原则的时候是这样设计的,如果我们现在想给公孙离来一个最近新出的皮肤“记忆之芯”的话,假设我们让它状态为2,那我们是不是又要去修改原代码,加一个当state==2时候的情况?那王者经常出皮肤,每次都要这样去修改原代码?是不是很麻烦,而且可能会引起未知的错误,因此我们这里如果采用开闭原则的话代码会怎么样呢?我们举个简单的例子:

public class GongSunLi { //公孙离类
    public void currentSkin(){
        System.out.println("当前使用原皮");
    }
}
public class GongSunLiBanSheng extends GongSunLi{ //公孙离伴生皮类
    @Override
    public void currentSkin() {
        System.out.println("当前使用伴生皮肤");
    }
}
public class GongSunLiNewSkin extends GongSunLi { //公孙离记忆之芯皮肤类
    @Override
    public void currentSkin() {
        System.out.println("当前使用皮肤是:记忆之芯");
    }
}

可见,如果我们采用“开闭原则”的话,每次增加一个皮肤,我们只需要去扩展公孙离类就行了,当然!这里只是举一个简单的例子,只是想大家体会到“对扩展开放,对修改关闭”的好处!如果按上述这样来设计的话,那肯定会引起“类爆炸了”,因此上述只是一个“不恰当”的例子!只是希望能让大家体会“开闭原则”的思想!

二、里氏代换原则

里氏代换原则:任何基类可以出现的地方,子类一定可以出现。通俗理解:子类可以扩展父类的功能,但不能改变父类原有的功能。换句话说,子类继承父类时,除添加新的方法完成新增功能外,尽量不要重写父类的方法。
如果通过重写父类的方法来完成新的功能,这样写起来虽然简单,但是整个继承体系的可复用性会比较差,特别是运用多态比较频繁时,程序运行出错的概率会非常大。
下面看一个里氏替换原则中经典的一个例子
【例】正方形不是长方形。
在数学领域里,正方形毫无疑问是长方形,它是一个长宽相等的长方形。所以,我们开发的一个与几何图形相关的软件系统,就可以顺理成章的让正方形继承自长方形。
代码如下
长方形类( Rectangle ):
public class Rectangle {
    private double length;
    private double width;

    public double getLength() {
        return length;
    }

    public void setLength(double length) {
        this.length = length;
    }

    public double getWidth() {
        return width;
    }

    public void setWidth(double width) {
        this.width = width;
    }
}
正方形( Square ):
由于正方形的长和宽相同,所以在方法 setLength setWidth 中,对长度和宽度都需要赋相同值。
public class Square extends Rectangle {
    public void setWidth(double width) {
        super.setLength(width);
        super.setWidth(width);
    }

    public void setLength(double length) {
        super.setLength(length);
        super.setWidth(length);
    }
}
RectangleDemo 是我们的软件系统中的一个组件,它有一个 resize 方法依赖基类 Rectangle
resize 方法是 RectandleDemo 类中的一个方法,用来实现宽度逐渐增长的效果。
public class RectangleDemo {
    public static void resize(Rectangle rectangle) {
        while (rectangle.getWidth() <= rectangle.getLength()) {
            rectangle.setWidth(rectangle.getWidth() + 1);
        }
    }

    //打印长方形的长和宽
    public static void printLengthAndWidth(Rectangle rectangle) {
        System.out.println(rectangle.getLength());
        System.out.println(rectangle.getWidth());
    }

    public static void main(String[] args) {
        Rectangle rectangle = new Rectangle();
        rectangle.setLength(20);
        rectangle.setWidth(10);
        resize(rectangle);
        printLengthAndWidth(rectangle);
        System.out.println("============");
        Rectangle rectangle1 = new Square();
        rectangle1.setLength(10);
        resize(rectangle1);
        printLengthAndWidth(rectangle1);
    }
}
我们运行一下这段代码就会发现,假如我们把一个普通长方形作为参数传入 resize 方法,就会看到长方形宽度逐渐增长的效果,当宽度大于长度, 代码就会停止,这种行为的结果符合我们的预期;假如我们再把一个正方形作为参数传入resize 方法后,就会看到正方形的宽度和长度都在不断增长,代码会一直运行下去,直至系统产生溢出错误。所以,普通的长方形是适合这段代码的,正方形不适合。 我们得出结论:在resize方法中, Rectangle 类型的参数是不能被 Square类型的参数所代替,如果进行了替换就得不到预期结果。因此, Square 类和 Rectangle 类之间的继承关系违反了里氏代换原则。

三、依赖倒转原则

依赖倒转原则高层模块不应该依赖低层模块,两者都应该依赖其抽象;抽象不应该依赖细节,细节应该依赖抽象。简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合。

这就是经典的多态思想!

比如:人这个类想养一只宠物,现在有dog类、cat类。如果我们直接在代码里面写死,那后面如果某个人的对象想换一只宠物养,那不就要去修改原代码了吗?不就违反了我们的“开闭原则”了吗?那后面如果他又想换其他的呢?那不就又要改?!这里我们举例代码如下:

public class Cat { //
    public void print(){ //打印当前宠物种类
        System.out.println("我是一只猫");
    }
}
public class Dog {
    public void print(){ //打印当前宠物种类
        System.out.println("我是一只狗");
    }
}
public class Person { //人类
    Dog dog=new Dog();
    public void print(){//打印当前养了什么宠物
        dog.print();
    }
}

可见,如果现在这个人想养一只猫,那我就要去修改原代码,将Dog改成Cat,因此这极其不方便,如果我们利用了依赖倒转原则,也可以理解成多态的思想,那代码会怎么样呢?代码如下:

public interface Pet { //宠物接口
    public void print();
}
public class Cat implements Pet{ // 猫类
    public void print(){ //打印当前宠物种类
        System.out.println("我是一只猫");
    }
}
public class Dog implements Pet{
    public void print(){ //打印当前宠物种类
        System.out.println("我是一只狗");
    }
}
public class Person { //人类
    Pet pet;
    Person(Pet pet){
        this.pet=pet; //直接告诉想养什么宠物
    }
    public void print(){//打印当前养了什么宠物
        pet.print();
    }
}

可见,这个时候如果我们想换一种种类的宠物养,那就new对象的时候,直接传入想养什么种类的宠物即可!

四、接口隔离原则

接口隔离原则客户端不应该被迫依赖于它不使用的方法;一个类对另一个类的依赖应该建立在最小的接口上。

这里我们直接继个例子,大家就知道接口隔离原则的意思了。

现在有一个食品接口,里面的属性有:①温度 ②忌口  ③甜度  ④咸度  ⑤是否加辣  

然后我们有各种各样的食品实现类,比如青椒炒肉、大盘鸡、冰淇淋蛋糕。但是,大家有没有发现一个问题,以上实现类并不是需要食品接口里面的所有属性!比如冰淇淋蛋糕并不需要我们去告知
温度,因为它是冰淇淋啊!青椒炒肉也不需要我们去告知甜度!也就是我们的食品接口太广泛了!我们明明可以把①温度 ②忌口  ③甜度  ④咸度  ⑤是否加辣 ,单独设计成一个个接口,而不是作为食品接口的属性,接口隔离原则也就是这个意思!

五、迪米特法则

迪米特法则又叫最少知识原则。
其含义是:如果两个软件实体无须直接通信,那么就不应当发生直接的相互调用,可以通过第三方转发该调用。其目的是降低类之间的耦合度,提高模块的相对独立性。
迪米特法则中的 朋友 是指:当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等,这些对象同当前对象存在关联、聚合或组合关系,可以直接访问这些对象的方法。
这里如果学过动态代理的同学肯定很好理解这个法则,因为动态代理就是基于这个设计原则去实现的!当然,我们后端写程序时,为什么Controller层只能调用Service层?有些功能明明Service层啥都不干,直接调用Dao层不就好了吗?这个也是利用了迪米特法则来设计,因为这样便于管理,降低耦合度!

六、合成复用原则

合成复用原则是指:尽量先使用组合或者聚合等关联关系来实现,其次才考虑使用继承关系来实现。
通常类的复用分为继承复用和合成复用两种。
继承复用虽然有简单和易实现的优点,但它也存在以下缺点:
1. 继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类,父类对子类是透明的,所以这种复用又称为“ 白箱 复用。
2. 子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化,这不利于类的扩展与维护。
3. 它限制了复用的灵活性。从父类继承而来的实现是静态的,在编译时已经定义,所以在运行时不可 能发生变化。
采用组合或聚合复用时,可以将已有对象纳入新对象中,使之成为新对象的一部分,新对象可以调用已有对象的功能,它有以下优点:
1. 它维持了类的封装性。因为成分对象的内部细节是新对象看不见的,所以这种复用又称为 黑箱
复用。
2. 对象间的耦合度低。可以在类的成员位置声明抽象。
3. 复用的灵活性高。这种复用可以在运行时动态进行,新对象可以动态地引用与成分对象类型相同的对象。
例如我们之前说“开闭原则”时举的那个不恰当的例子,我们就是通过继承来实现公孙离每次新出一个皮肤时就多写一个子类,但是我们也说了这样会引起“类爆炸”,因为王者那么多英雄,每个英雄又那么多皮肤,可见如果我们每次是通过继承的方式来,那该多么多么多类啊!!!想想就难管理!记得之前我在写一个分布式项目时,大概所有功能加起来有上百个类,当时找一个类真的眼睛都快找花了!而且很难管理!如果我们用继承的方式去写王者荣耀,哎!想想都恐怖!

结语:以上是软件设计的六大原则,希望大家好好理解里面的思想,这对于我们以后学习设计模式有很大的帮助!因为设计模式都是基于上述思想去设计的!

(笔者接下来会慢慢更新设计模式的内容,大家点个关注!谢谢大家!)

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值