软件设计七大原则

最新推荐文章于 2023-12-21 13:25:02 发布
原创 最新推荐文章于 2023-12-21 13:25:02 发布 · 649 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

设计原则：

在软件设计中应该遵循的原则，这样比较容易设计出易扩展、易维护、可重用、灵活性高的软件架构。设计原则是设计模式的基础，每个设计模式或多或少都会遵循一个以上的设计原则。

单一职责原则：

对一个类或者方法来说，只负责一项职责，如果一个类负责多个职责的话，某个职责的修改可能会导致令一个职责错误，所以要将职责分离开来。可以在类级别或者方法级别上遵守单一职责原则。

UML图及代码：
改进前：
在这里插入图片描述

/**
 * 交通工具
 */
public class Vehicle {

    public static void main(String[] args) {
        Vehicle vehicle = new Vehicle();
        System.out.println(vehicle.run("汽车"));
        System.out.println(vehicle.run("火车"));
        System.out.println(vehicle.run("飞机"));
    }

    public String run(String name){
        return name + "在公路上行驶";
    }
}

//飞机在公路上行驶明显是不符合逻辑的，该代码就没有遵循单一职责原则，因为在天空中的交通工具跟在公路上的交通工具的职责是不一样的，所以要分离开来。

改进后：
在这里插入图片描述

public class RoadVehicle {

    public static void main(String[] args) {
        RoadVehicle roadVehicle = new RoadVehicle();
        SkyVehicle skyVehicle = new SkyVehicle();
        System.out.println(roadVehicle.run("汽车"));
        System.out.println(roadVehicle.run("火车"));
        System.out.println(skyVehicle.run("飞机"));
    }

    public String run(String name){
        return name + "在公路上行驶";
    }
}

public class SkyVehicle {
    public String run(String name){
        return name + "在天空中上飞行";
    }
}

//把职责分离开来，天空的交通工具只负责天空飞行的职责，公路上的交通工具只负责在公路上行驶的职责。

单一职责的优点和细节：

  1. 可以降低类的复杂度，因为一个类只负责一项职责，类也相对简单了。
  2. 提高了维护性和可读性。
  3. 降低变更引起的风险。
  4. 通常情况下，我们应该遵守单一职责原则，只有在代码逻辑足够简单的情况下才能违反单一职责原则。只有类中的方法足够少，才能在方法层面违反该原则。
接口隔离原则：

客户端不应该依赖于他不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上。例如：A依赖于B，B实现了接口C，A类就要用到C接口的所有方法。

uml图及代码：
在这里插入图片描述

public interface A {
    void operator1();
    void operator2();
    void operator3();
    void operator4();
    void operator5();
}

public class B implements A {
    @Override
    public void operator1() {
        System.out.println("B实现A-->operator1()");
    }

    @Override
    public void operator2() {
        System.out.println("B实现A-->operator2()");
    }

    @Override
    public void operator3() {
        System.out.println("B实现A-->operator3()");
    }

    @Override
    public void operator4() {
        System.out.println("B实现A-->operator4()");
    }

    @Override
    public void operator5() {
        System.out.println("B实现A-->operator5()");
    }
}
public class C implements A {
    @Override
    public void operator1() {
        System.out.println("C实现A-->operator1()");
    }

    @Override
    public void operator2() {
        System.out.println("C实现A-->operator2()");
    }

    @Override
    public void operator3() {
        System.out.println("C实现A-->operator3()");
    }

    @Override
    public void operator4() {
        System.out.println("C实现A-->operator4()");
    }

    @Override
    public void operator5() {
        System.out.println("C实现A-->operator5()");
    }
}

public class D {

    public void useOperator1(C c){
        c.operator1();
    }

    public void useOperator2(C c){
        c.operator2();
    }

    public void useOperator3(C c){
        c.operator3();
    }
}

public class E {

    public void useOperator1(B b){
        b.operator1();
    }

    public void useOperator4(B b){
        b.operator4();
    }

    public void useOperator5(B b){
        b.operator5();
    }
}

//这个是违反了接口隔离原则的，因为类D依赖了类C却只使用了接口A的其中三个方法而已，类E依赖了类B却只使用了接口A的其中三个方法而已。

改进后：
在这里插入图片描述

public interface A {

    void operator1();
}

public interface B {
    void operator2();
    void operator3();
}

public interface C {
    void operator4();
    void operator5();
}

public class D implements A,B {
    @Override
    public void operator1() {
        System.out.println("D 实现 A-->operator1()");
    }

    @Override
    public void operator2() {
        System.out.println("D 实现 B-->operator2()");
    }

    @Override
    public void operator3() {
        System.out.println("D 实现 B-->operator3()");
    }
}

public class E implements A,C{

    @Override
    public void operator1() {
        System.out.println("E 实现 A-->operator1()");
    }

    @Override
    public void operator4() {
        System.out.println("E 实现 C-->operator4()");
    }

    @Override
    public void operator5() {
        System.out.println("E 实现 C-->operator5()");
    }
}

public class F {
    public void useOperator1(D d){
        d.operator1();
    }

    public void useOperator2(D d){
        d.operator2();
    }

    public void useOperator3(D d){
        d.operator3();
    }
}

public class G {

    public void useOperator1(E e){
        e.operator1();
    }

    public void useOperator4(E e){
        e.operator4();
    }

    public void useOperator5(E e){
        e.operator5();
    }
}

//将本来的接口A拆分成了A、B、C ，然后D类实现接口A、B，E类实现接口A、C，这样就达到了接口隔离的原则。

依赖倒置原则：

  1. 高层模块（调用方）不应该依赖低层模块（提供方），二者都应该依赖其抽象。
  2. 抽象不应该依赖细节，细节应该依赖抽象。依赖传递都传递抽象，接口或者抽象类。
  3. 依赖倒置的中心思想是面向接口编程。充分利用多态。
  4. 依赖倒置原则基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多，以抽象为基础搭建的架构比以细节为基础搭建的架构要稳定得多，在java中，抽象指的是接口或抽象类，细节就是具体的实现类。
  5. 使用接口或者抽象类的目的是制定好规范，而不涉及任何具体操作，把展现细节的任务交给他们的实现类去完成。

依赖传递的三种方法：

  1. 接口。
  2. setter方法。
  3. 构造器。
    UML图及代码：
    改进前：
    在这里插入图片描述
public class RoadVehicle {

	private String name;
	public void setName(String name){
		this.name = name;
	}
    public void run(){
        System.out.println(name + "在公路上行驶");
    }
}


public class SkyVehicle {
	private String name;
	public void setName(String name){
		this.name = name;
	}
    public void run(){
        System.out.println(name + "在天空中飞行");
    }
}

public class TestVehicle {

    public void runRoadVehicle(RoadVehicle roadVehicle){
        roadVehicle.run();
    }

    public void runSkyVehicle(SkyVehicle skyVehicle){
        skyVehicle.run();
    }
}

//分析：TestVehicle 类是高层模块（调用方），依赖了SkyVehicle、RoadVehicle底层模块，而没有依赖其抽象，违反了依赖倒置原则，所以如果每次增加一个新的交通工具TestVehicle 类就要新增一个方法。

改进后：
在这里插入图片描述



public interface Vehicle {
    void run();
}

public class RoadVehicle implements Vehicle{

    private String name;

    public void setName(String name) {
        this.name = name;
    }

    @Override
    public void run(){
        System.out.println(name + "在公路上行驶");
    }
}

public class SkyVehicle implements Vehicle{
    private String name;

    public void setName(String name) {
        this.name = name;
    }

    @Override
    public void run(){
        System.out.println(name + "在天空中飞行");
    }
}

public class TestVehicle {

    public void runVehicle(Vehicle Vehicle){
        Vehicle.run();
    }

    public static void main(String[] args) {
        TestVehicle testVehicle = new TestVehicle();
        testVehicle.runVehicle(new RoadVehicle());
        testVehicle.runVehicle(new SkyVehicle());
    }

}

//分析：改进后，RoadVehicle 、SkyVehicle 会实现Vehicle接口，然后TestVehicle 没有依赖低层模块，而是依赖其抽象，这样，每当新增一个交通工具时，高层接口无需改变。

依赖倒置原则的注意事项和细节：

  1. 底层模块尽量都要有抽象父类或接口。或者两者都有。
  2. 变量的声明一般都用抽象父类或者接口，然后将引用指向实际的实现类（多态），这样引用变量和时间对象之间会有一个缓冲层，利于程序扩展和优化。
  3. 继承时遵循里氏替换原则。

里氏替换原则：

面向对象中的继承性的思考和说明：

  1. 继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然他不强制要求所有子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。
  2. 继承在给程序设计带来便利的同时，也会带来弊端，比如继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他类所继承，则当这个类需要修改时，必须考虑到所有子类，并且父类修改后，所有涉及到子类的功能都有可能故障。
  3. 而里氏替换原则是对继承的规范和约束。

里氏替换原则定义：有类A和B，B继承A，OA是A的对象，OB是B的对象，一个程序P调用OA对象的所有方法，如果换成调用OB对象的这些方法的话，对这个程序P的行为没有任何影响，则符合里氏替换原则。也就是说子类不应该重写父类已实现的方法，调用父类的方法与调用子类的相应方法所产生的行为一致。

UML图及代码：
改进前：
在这里插入图片描述

public class A {
    /**
     * 加法
     * @param member1
     * @param member2
     * @return
     */
    public int fun(int member1,int member2){
        return member1 + member2;
    }
}

public class B extends A{
    /**
     * 减法
     * @param member1
     * @param member2
     * @return
     */
    @Override
    public int fun(int member1,int member2){
        return member1 - member2;
    }
}

public class TestAB {

    public static void main(String[] args) {
        A a = new A();
        A b = new B();
        System.out.println(a.fun(1,2));
        System.out.println(b.fun(1,2));
    }
}

//分析，由于子类重写了父类已经实现的方法，所以调用这两个会出现不一样的结果，这无疑会使系统更加地复杂。

改进后：
在这里插入图片描述

public abstract class Base {
    public abstract int fun(int member1,int member2);
}

public class A extends Base{
    /**
     * 加法
     * @param member1
     * @param member2
     * @return
     */
    @Override
    public int fun(int member1,int member2){
        return member1 + member2;
    }
}

public class B extends Base {
    /**
     * 减法
     * @param member1
     * @param member2
     * @return
     */
    @Override
    public int fun(int member1,int member2){
        return member1 - member2;
    }
}

public class TestAB {

    public static void main(String[] args) {
        A a = new A();
        B b = new B();
        System.out.println(a.fun(1,2));
        System.out.println(b.fun(1,2));
    }
}

//分析：使用了更抽象的类base，然后子类各自实现其抽象方法，使得程序更加地清晰。

在使用继承时，尽量遵循里氏替换原则，不要重写已实现父类的方法。

里氏替换原则告诉我们，继承实际上让两个类的耦合性增强了，在适当情况下可以通过聚合、组合、依赖来解决问题。

通常做法：原来的父类和子类继承同一个更抽象的基类，原有的继承去掉，采用依赖、聚合、组合。等关系代替。

开闭原则：

开闭原则：

  1. 是编程中最基础，最重要的设计原则。是其他原则的基础。其他原则都能看到这个原则的身影。
  2. 一个软件实体，如类，模块和函数应该对扩展开放（提供方），对修改关闭（使用方），用抽象构建框架，用实现扩展细节。
  3. 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化（比如新增类），而不是修改已有的代码来实现。
  4. 编程中遵循其他原则，以及使用设计模式的目的就是遵循开闭原则。

代码跟依赖倒置原则类似。

迪米特原则：

  1. 一个对象应该和其他对象保持最小的了解。
  2. 类与类之间的关系越密切，耦合度越大。
  3. 迪米特法则又叫最少知道原则，即一个类对自己依赖的类知道地越少越好。也就是说对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部，对外除了提供public方法之外，不对外泄露任何信息。
  4. 迪米特法则还有个更简单的定义：只与直接朋友通信。

直接朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式有很多：依赖、关联、组合、聚合等。其中：我们称出现在成员变量、方法参数、方法返回值的类为直接的朋友，而出现在局部变量的类不是直接朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。

就是别的类的逻辑信息不要出现在令一个类。而是完美的封装在原来的类里面，只暴露public方法供调用。

迪米特法则的注意事项和细节：

  1. 迪米特法则的核心是降低类之间的耦合。
  2. 由于每个类都减少了不必要的依赖，所以迪米特法则只是要求降低类（对象间的耦合关系），并不是完全消除耦合。

合成复用原则：

原则是尽量使用合成/聚合/组合的方式代替继承。

设计原则的核心思想：

  1. 找出应用中可能需要变化之处，把它们独立起来，不要和那些不需要变化的代码混在一起。
  2. 针对接口编程而不是针对实现编程。
  3. 为交互对象之间的松耦合而努力。
软件架构设计与模式之：扩展性与可维护性设计
AI天才研究院
10-30 1501
作者：禅与计算机程序设计艺术 1.背景介绍 随着互联网应用的普及和发展，软件系统的复杂度和规模也在不断扩大。软件架构设计作为软件工程的关键环节之一，越来越受到重视。其中，扩展性和可维护性是衡量软件架构设计质量的重要指标，也是软件开发团队面临的重要挑战。本文将探讨如何设计和实现具有良好扩展性和可维护性
设计模式—7大设计原则
多一天，多一点
07-17 659
设计模式—7大设计原则 一、设计模式的目的 软件开发过程中，开发人员面临着来自代码间的耦合性，内聚性以及可维护性，可扩展性，重用性，灵活性等多方面的挑战，设计模式是为了让程序(软件)具有更好的： 代码重用性 (即：相同功能的代码，不用多次编写) 可读性 (即：编程规范性, 便于其他程序员的阅读和理解) 可扩展性 (即：当需要增加新的功能时，非常的方便，称为可维护) 可靠性 (即：当我们增加新的功能后，对原来的功能没有影响) 使程序呈现高内聚，低耦合的特性分享金句： 设计模式包含了面向对
可维护性的度量和设计原则（1）
wllmkng的博客
07-03 3354
文章目录可维护性的度量和设计原则软件维护和演化软件维护软件演化可维护性的指标可维护性的几个名字关于可维护性的问题一些可维护性的指标模块化设计和模块化原则模块化编程评估模块性的五个标准模块设计的五个规则**Information Hiding（信息隐藏）** 可维护性的度量和设计原则 软件维护和演化 软件维护 软件维护指在软件发布后对软件中的错误进行修改以提升性能或者其他特性的活动。 软件维护是软件产品最困难的方面，因为它与其他所有的软件开发阶段都相关。 修复代码后 测试修改是否正常：使用特殊构造的测试用
3.软件设计原则
qq_43626215的博客
03-05 487
软件设计原则 在软件开发中。为了提高软件系统的可维护性和可复用性，增加软件的可扩展性和灵活性，程序员要尽量根据6条原则来开发程序，从而提高软件开发效率、节约软件开发成本和维护成本 1.开闭原则 对扩展开发，对修改关闭。在程序需要进行扩展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。 想要达到这样的效果，我们需要使用接口和抽象类。 因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生来的实现类来进行扩展，
软件界面设计守则之规范性详细细则
11-16 310
在上一篇的分享文章中，我们分享了软件界面设计中的易用性细则，今天我们来分享下软件界面设计中的规范性细则。通常界面设计都按Windows界面的规范来设计，即包含“菜单条、工具栏、工具箱、状态栏、滚动条、右键快捷菜单”的标准格式，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。那么，具体到...
软件设计原则
weixin_47354101的博客
09-11 479
一、软件设计原则概述 软件的可维护性和可复用性是两个非常重要的用于衡量软件质量的属性，所以在开发软件中，我们要为了提高软件系统的可维护性和可复用性，故我们要根据7条原则来开发程序，以便设计出软件系统，实现可维护性服复用的目标。 二、软件设计7条原则 单一职责原则 开闭原则 里氏代换原则 依赖倒转原则 接口隔离原则 合成复用原则 迪米特原则 三、软件设计原则详解 （一）、单一职责原则（Single Responsibility Principle，SRP） 1、定义 一个对象应该只包含单一的职责，并且该职
软件设计七大原则详解 1. 单一职责原则（Single Responsibility Principle, SRP） 1.1 原则定义 1.2 为什么需要单一职责原则？ 1.3 违反单一职责原则的例子
最新发布
04-24
软件设计七大原则详解 1. 单一职责原则（Single Responsibility Principle, SRP） 1.1 原则定义 1.2 为什么需要单一职责原则？ 1.3 违反单一职责原则的例子 1.4 应用单一职责原则的改进 1.5 现实应用场景 1.6 单一...
软件设计的七大原则（OOD）
03-26
软件设计的七大原则（OOD） software设计的七大原则是指在软件设计中遵守的一些基本原则，以提高软件的可复用性、灵活性、可扩展性和可维护性。其中包括SRP（单一职责原则）、OCP（开闭原则）、LSP（里氏替换原则）...
一句话总结软件设计七大原则
NewBeeMu的博客
04-14 560
开闭原则、里氏替换原则、依赖倒置原则、单一职责原则、接口隔离原则、迪米特法则和合成复用原则这7 种设计原则是软件设计模式必须尽量遵循的原则，是设计模式的基础。 在实际开发过程中，并不是一定要求所有代码都遵循设计原则，而是要综合考虑人力、时间、成本、质量，不刻意追求完美，要在适当的场景遵循设计原则。这体现的是一种平衡取舍，可以帮助我们设计出更加优雅的代码结构。 各种原则要求的侧重点不同，下面我们分别用一句话归纳总结软件设计模式的七大原则，如下表所示。 设计原则 一句话归纳 目的 开闭原则 对扩
软件设计的七大原则.doc
08-06
软件设计的七大原则 软件设计的七大原则是软件设计的精髓所在，这七大原则分别是开闭原则、里氏代换原则、依赖倒置原则、接口隔离原则、合成/聚合复用原则、迪米特法则和抽象类原则。 一、 开闭原则（OCP） 开闭...
软件设计原则-面向对象设计七大原则.zip
12-24
软件设计原则-面向对象设计七大原则.zip 面向对象和C语言完全不是一种思考问题的方式,面向对象是种哲学思想,只有明白了其核心思想,才能以不变应万变 只有吃透面向对象的七大设计原则,比如:依赖倒置原则,迪米特法则等...
【软件构造】设计易于复用和维护的软件（2）（第10-11讲）
CyanTangerine的博客
06-12 214
纠错性、适应性、完善性、预防性 - 高内聚、低耦合（圈复杂度、代码行数） # 10.1 五类设计原则：SOLID - SRP：单一责任原则：一个类一个功能一个原因变化 - OCP：开放-封闭原则：扩展性开放、修改封闭（把不变的都放到父类型，变化的放到子类型，有变化不修改，而是创建新的类型） - LSP：Liskov替换原则 - ISP：接口聚合原则（不能强迫客户端依赖于它们不需要的接口：只提供必需的接口） 将大接口拆分成多个小接口，尽量不要使用UnsupportedOperationException。 .
设计模式之软件开发原则（1）开闭原则和依赖倒置原则
weixin_34239592的博客
11-30 248
开闭原则 定义 所谓开闭原则就是一个软件实体如类、模块和函数应该对扩展开放、对修改关闭。 强调用抽象构建框架，实现实现拓展细节。 有优点是提高软件的复用性和易维护展性。是面向对象的最基本原则。 依赖倒置原则 定义 高层模块不应该依赖底层模块，二者都应该依赖其抽象。 抽象不应该依赖细节：细节应该依赖抽象。 针对接口编程，不要针对实现编程。 优点 降低耦合提高稳定性，提高代码的可读性和易维护性。减少代...
软件工程(软件维护之易维护性)
Gabriel的专栏
04-09 6372
软件易维护性是指理解、改正、改动、改进软件的难易程度。通常影响软件易维护性的因素有易理解性、易测试性和易修改性 易维护性　　是指维护人员为纠正软件系统出现的错误或缺陷，以及为满足新的要求而理解、修改和完善软件系统的难易程度。提高可维护性是决定软件工程方法论所有步骤的关键目标。1.易理解性易理解性被定义为人们通过阅读源代码和相关文档了解软件系统的结构、接口、功能、内部过程以及如何运行
六大设计原则：构建优雅、可维护和可扩展的软件
『愚』的博客
11-06 756
单一职责原则要求一个类应该只有一个引起变化的原因。换句话说，一个类应该只有一个职责。
【设计模式】六大原则
滕柳
02-03 724
设计模式
系统设计原则
热门推荐
NightTravelDeity的专栏
05-28 2万+
以技术先进、系统实用、结构合理、产品主流、低成本、低维护量作为基本建设原则，规划系统的整体构架。 先进性： 在产品设计上，整个系统软硬件设备的设计符合高新技术的潮流，媒体数字化、压缩、解压、传输等关键设备均处于国际领先的技术水平。在满足现期功能的前提下，系统设计具有前瞻性，在今后较长时间内保持一定的技术先进性。 安全性： 系统采取全面的安全保护措施，具有防病毒感染、防黑客攻击措施，同时在防
可维护性的度量和设计原则（2）
wllmkng的博客
07-06 481
文章目录可维护性的度量和设计原则（2）面向对象的设计原则：SOLIDSingle Responsibility Principle（SRP）Open/Closed Principle（OCP）Liskov Substitution Principle（LSP）Interface Segregation Principle（ISP）Dependency Inversion Principle（DIP）面向对象的设计原则：GRASPGRASPResponsibilityGRASP中的一些角色 可维护性的度量和设
软件设计模式：六大设计原则
浩泽学编程的博客
12-21 3293
在软件开发中，为了提高软件系统的可维护性和可复用性，增加软件的可扩展性和灵活性，程序员要尽量根据6条原则来开发程序，从而提高软件开发效率、节约软件开发成本和维护成本。六大设计原则：开闭原则、里氏代换原则、依赖倒转原则、接口隔离原则、迪米特原则、合成复用原则。以上就是软件设计模式六大设计原则的讲解。
里式替换原则：软件设计七大原则详解
里式替换原则是软件体系架构七大设计原则之一，它在面向对象编程中扮演着关键角色。这一原则的核心概念是子类型关系，即如果类型S的对象可以安全、无副作用地被类型T的对象替换，而不会影响程序的预期行为，那么S被...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值