7大设计原则

于 2021-05-16 14:22:34 发布
阅读量144 收藏
点赞数 1
分类专栏： 23种设计模式 文章标签： 设计模式 java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_44892120/article/details/116890852
版权

设计原则

单一职责原则

介绍

对类而言，即一个类应该只负责一项职责。如果类A负责两个不同的职责：职责一，职责二。当职责一发生变动而改动A时，可能造成职责2执行错误，所以需要将类A的粒度分为A1和A2。

作用

  1. 降低类的复杂度，一个类只负责一 项职责

  2. 提高类的为维护性，可读性

  3. 降低变更引起的风险

  4. 通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则。
    在这里插入图片描述
    ​ （注：上图不是真正意义上的单一职责原则）

接口隔离原则

介绍

在这里插入图片描述

通过接口隔离原则调整为如下
在这里插入图片描述

interface I1 {
	public void method1();
}

interface I2 {
	public void method2();
	public void method3();
}

interface I3 {
	public void method4();
	public void method5();
}

class A{
	public void depend1(I1 i){
		i.method1();
	}
	public void depend2(I2 i){
		i.method2();
	}
	public void depend3(I2 i){
		i.method3();
	}
}

class B implements I1, I2{
	public void method1() {
		System.out.println("类B实现接口I1的方法1");
	}
	public void method2() {
		System.out.println("类B实现接口I2的方法2");
	}
	public void method3() {
		System.out.println("类B实现接口I2的方法3");
	}
}

class C{
	public void depend1(I1 i){
		i.method1();
	}
	public void depend2(I3 i){
		i.method4();
	}
	public void depend3(I3 i){
		i.method5();
	}
}

class D implements I1, I3{
	public void method1() {
		System.out.println("类D实现接口I1的方法1");
	}
	public void method4() {
		System.out.println("类D实现接口I3的方法4");
	}
	public void method5() {
		System.out.println("类D实现接口I3的方法5");
	}
}

依赖倒转原则

介绍

一种表述： 抽象不应当依赖于细节；细节应当依赖于抽象。
另一种表述： 要针对接口编程，不要针对实现编程。
针对接口编程的意思就是说，应当使用Java接口和抽象Java类进行变量的类型声明、参量的类型声明、方法的返回类型声明，以及数据类型的转换等。
不要针对实现编程的意思就是说，不应当使用具体Java类进行变量的类型声明、参量的类型声明、方法的返回类型声明，以及数据类型的转换等。

public class dependecy {
    public static void main(String[] args) {
        Persion persion = new Persion();
        persion.receive(new Email());
        persion.receive(new Weixin());

    }

}
//定义接口
interface Inreceive{
    public String getinfo();

}
//实现接口
class Email implements Inreceive{
    public String getinfo(){
        return "电子邮件:小白你好";
    }

}
class Weixin implements Inreceive{
    public String getinfo(){
        return "微信：小白你好";
    }

}
class Persion{
    public void receive(Inreceive inreceive){
        System.out.println(inreceive.getinfo());
    }
}
通过接口传递实现依赖

在这里插入图片描述

通过构造方法依赖传递

在这里插入图片描述

通过setter方法传递

在这里插入图片描述

里氏替换原则

介绍

里氏替换原则的另一个简短的定义是“所有引用基类的地方必须能透明地使用其子类的对象”。这个可能更清楚点。如果你熟悉的掌握一门面向对象的语言，你应该都可以明白面向对象的继承，子类继承自父类的话，自然的就会继承父类的所有方法（当然前提是父类不要把方法声明为private）。
在面向对象中，继承有很多优点：
1代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；
2提高代码的重用性；
3子类可以形似父类，但又异于父类，“龙生龙，凤生凤，老鼠生来会打洞”是说子拥有父的“种”，“世界上没有两片完全相同的叶子”是指明子与父的不同；
4提高代码的可扩展性，实现父类的方法就可以“为所欲为”了，君不见很多开源框架的扩展接口都是通过继承父类来完成的；
5提高产品或项目的开放性。

里氏替换原则为良好的继承定义了一个规范，一句简单的话包含了4层含义。

1、子类必须完全实现父类的方法
在类中调用其它类时务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计以及违背了LSP原则。
如果子类不能完整的实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。

2、子类可以拥有自己的“个性”
子类可以拥有自己的方法和属性，也可以重写（Override）或重载（Overload）父类的方法。从而拥有自己的“个性”。但这里提起是为了再次说明一个问题——里氏替换原则可以正着用，但不能反过来使用，即子类出现的地方，父类未必可以胜任。

3、覆盖或实现父类方法时输入参数可以被放大
父类的一个方法的形参是一个类型T，子类的相同方法（重载或重写）的形参是S，那么里氏替换原则就要求S必须大于等于T。也就是说，要么S和T是同一类型，要么S是T的父类。

4、覆盖或实现父类方法时输出结果可以被缩小
父类的一个方法返回值是一个类型T，子类的相同方法（重载或重写）的返回值是S，那么里氏替换原则就要求S必须小于等于T。也就是说，要么S和T是同一类型，要么S是T的子类。

开闭原则（OCP原则）

介绍

开闭原则（Open-Closed Principle, OCP）是指一个软件实体如类、模块和函数应该对扩展开放， 对修改关闭。所谓的开闭，也正是对扩展和修改两个行为的一个原则。强调的是用抽象构建框架，用实 现扩展细节。可以提高软件系统的可复用性及可维护性。开闭原则，是面向对象设计中最基础的设计原则。它指导我们如何建立稳定灵活的系统，例如：我们版本更新，我尽可能不修改源代码，但是可以增 加新功能。

生活例子

在现实生活中对于开闭原则也有体现。比如，很多互联网公司都实行弹性制作息时间，规定每天工 作 8 小时。意思就是说，对于每天工作 8 小时这个规定是关闭的，但是你什么时候来，什么时候走是开 放的。早来早走，晚来晚走。

核心思想

面向抽象编程。

迪米特法则

介绍

迪米特法则（Law ofDemeter，LoD）又叫最小知识原则（least knowledge principle，lkp），定义为：一个对象对其它对象尽可能少的理解。 迪米特法则又叫最少知道原则，最早是在1987年由美国Northeastern University的Ian Holland提出。通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。迪米特法则还有一个更简单的定义：只与直接的朋友通信。首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部

举例

有一个集团公司，下属单位有分公司和直属部门，现在要求打印出所有下属单位的员工ID。先来看一下违反迪米特法则的设计。

//总公司员工
class Employee{
	private String id;
	public void setId(String id){
		this.id = id;
	}
	public String getId(){
		return id;
	}
}

//分公司员工
class SubEmployee{
	private String id;
	public void setId(String id){
		this.id = id;
	}
	public String getId(){
		return id;
	}
}

class SubCompanyManager{
	public List<SubEmployee> getAllEmployee(){
		List<SubEmployee> list = new ArrayList<SubEmployee>();
		for(int i=0; i<100; i++){
			SubEmployee emp = new SubEmployee();
			//为分公司人员按顺序分配一个ID
			emp.setId("分公司"+i);
			list.add(emp);
		}
		return list;
	}
}

class CompanyManager{

	public List<Employee> getAllEmployee(){
		List<Employee> list = new ArrayList<Employee>();
		for(int i=0; i<30; i++){
			Employee emp = new Employee();
			//为总公司人员按顺序分配一个ID
			emp.setId("总公司"+i);
			list.add(emp);
		}
		return list;
	}
	
	public void printAllEmployee(SubCompanyManager sub){
		List<SubEmployee> list1 = sub.getAllEmployee();
		for(SubEmployee e:list1){
			System.out.println(e.getId());
		}

		List<Employee> list2 = this.getAllEmployee();
		for(Employee e:list2){
			System.out.println(e.getId());
		}
	}
}

public class Client{
	public static void main(String[] args){
		CompanyManager e = new CompanyManager();
		e.printAllEmployee(new SubCompanyManager());
	}
}

注：现在这个设计的主要问题出在CompanyManager中，根据迪米特法则，只与直接的朋友发生通信，而SubEmployee类并不是CompanyManager类的直接朋友（以局部变量出现的耦合不属于直接朋友），从逻辑上讲总公司只与他的分公司耦合就行了，与分公司的员工并没有任何联系，这样设计显然是增加了不必要的耦合。按照迪米特法则，应该避免类中出现这样非直接朋友关系的耦合。修改后的代码如下:

class SubCompanyManager{
	public List<SubEmployee> getAllEmployee(){
		List<SubEmployee> list = new ArrayList<SubEmployee>();
		for(int i=0; i<100; i++){
			SubEmployee emp = new SubEmployee();
			//为分公司人员按顺序分配一个ID
			emp.setId("分公司"+i);
			list.add(emp);
		}
		return list;
	}
	public void printEmployee(){
		List<SubEmployee> list = this.getAllEmployee();
		for(SubEmployee e:list){
			System.out.println(e.getId());
		}
	}
}

class CompanyManager{
	public List<Employee> getAllEmployee(){
		List<Employee> list = new ArrayList<Employee>();
		for(int i=0; i<30; i++){
			Employee emp = new Employee();
			//为总公司人员按顺序分配一个ID
			emp.setId("总公司"+i);
			list.add(emp);
		}
		return list;
	}
	
	public void printAllEmployee(SubCompanyManager sub){
		sub.printEmployee();
		List<Employee> list2 = this.getAllEmployee();
		for(Employee e:list2){
			System.out.println(e.getId());
		}
	}
}

修改后，为分公司增加了打印人员ID的方法，总公司直接调用来打印，从而避免了与分公司的员工发生耦合。
迪米特法则的初衷是降低类之间的耦合，由于每个类都减少了不必要的依赖，因此的确可以降低耦合关系。但是凡事都有度，虽然可以避免与非直接的类通信，但是要通信，必然会通过一个“中介”来发生联系，例如本例中，总公司就是通过分公司这个“中介”来与分公司的员工发生联系的。过分的使用迪米特原则，会产生大量这样的中介和传递类，导致系统复杂度变大。所以在采用迪米特法则时要反复权衡，既做到结构清晰，又要高内聚低耦合。

合成复用原则

介绍

合成复用原则又称为组合/聚合复用原则(Composition/Aggregate Reuse Principle, CARP)，尽量使用对象组合，而不是继承来达到复用的目的。
合成复用原则就是在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用功能的目的。简言之：复用时要尽量使用组合/聚合关系（关联关系），少用继承

【小白撑伞】
关注
专栏目录
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值