前言

Object Oriented Programming 面向对象编程

1、六大原则

1.1、单一职责原则

就一个类而言，应该仅有一个引起它变化的原因。应该只有一个职责。
在这里插入图片描述

分析：
（1）init() 的作用是在登录时，对登录界面进行初始化
（2）display() 负责显示登录界面
（3）validate() 对当前界面用户输入的信息进行语法合法性检验，这个是语法验证，比如说用户的密码输入了没有，是否为空；年龄是否是负数…而不是对用户进行合法性验证
（4）getConnection() ,findUser() ，用户的信息保存在数据库中，要进行用户信息的验证，要连接数据库，并且在数据库中寻找输入的用户。
（5）main() ,是整个系统的入口
存在问题
根据单一职责原则，一个应该只有一个职责。现在的登录类大体来讲至少有3种职责。
（1）前面三个方法是合理的，都是与登录界面有关系的。初始化登录界面，展示登录界面，对界面输入的信息进行语法性检验。
（2）但是 getConnection() 和 findUser() 这两个方法是与业务逻辑有关系的，他们是用来判断一个用户是否是合法的。
（3）main() 方法与登录类没有关系，它是整个系统的入口。只不过是恰好存在系统入口是先进入登录界面的情况
单一职责另外一种定义：就一个类而言，应该仅有一个引起它变化的原因。从这个角度出发，登录类承担的职责过多，有多个引起它发生变化的原因。
比如说，界面发生变化，要修改 display() ；数据库里面的用户发生变化要修改 getConnection()；如果入口要增加一些触发工作，要修改 main()

重构：
在这里插入图片描述

1.2、开闭原则

一个软件实体应当对扩展开放，对修改关闭。
也就是说在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展，即在不修改源代码的情况下改变这个模块的行为。
在这里插入图片描述

重构：
（1）解决问题的思路：抽象化是开闭原则的关键，开闭原则要将可变的东西进行封装，将可变的东西进行封装变成稳定东西。
（2）找出可变点，在这里可变的就是按钮的形状，所以需要将它稳定下来，也就是进行抽象化，封装。
在这里插入图片描述

1.3、里氏替换原则

所有引用基类（父类）的地方必须能够透明地使用子类的对象。也就是能用子类替换父类，替换之后程序的行为没有发生改变。
子类可以扩展父类的功能，但不能改变父类原有的功能。
子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。
在这里插入图片描述

问题：几维鸟类重写了父类的方法，违背了里氏替换原则。
在这里插入图片描述

1.4、依赖倒置原则

依赖倒置原则(Dependence Inversion Principle)是程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。
在这里插入图片描述

问题：新增手机通信，就得修改People类
在这里插入图片描述

1.5、接口隔离原则

接口隔离原则：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。
也就是说，接口尽量细化，同一接口中的方法尽量少。

public interface CustomerDataDisplay {
	List<CustomerData> dataRead();
	void transformToXml();
	void createChart();
	void displayChart();
	void createReport();
	void displayReport();
}

现在有一个图表类ChartClass实现了CustomerDataDisplay接口，该类就要实现接口的全部方法，正常来说ChartClass只需要createChart()、displayChart()方法即可，因为CustomerDataDisplay接口方法太多了，承担了太多职责，颗粒度太大了ChartClass类不得不空实现其他方法，违背了接口隔离原则。
重构满足接口隔离原则

public interface DataHandler {
	List<CustomerData> dataRead();
}

public interface XMLTransformer {
	void transformToXml();
}

public interface ChartHandler {
	void createChart();void displayChart();
}

public interface ReportHandler {
	void createReport();void displayReport();
}

1.6、迪米特原则

迪米特法则（Law of Demeter）又叫作最少知道原则（The Least Knowledge Principle），通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。

Boss想从TeamLeader那里知道现有课程的总数。它们之间的调用关系应该为
Boss—>TeamLeader—>Course。
Boss与Course并无直接联系，所以在Boss类的方法中不应该出现Course类。一下给出合理的设计方案。

/**
* boss类不需要知道课程信息，只与TeamLeader通信
**/
public class Boss {
	public void commandCheckNumber(TeamLeader teamLeader){
		teamLeader.checkNumberOfCourses();
	}
}

/**
* TeamLeader 只与课程通信
**/
public class TeamLeader {
	public void checkNumberOfCourses(){
		List<Course> courseList = new ArrayList<Course>();
		for(int i = 0 ;i < 20;i++){
			courseList.add(new Course());
		}
		System.out.println("在线课程的数量是："+courseList.size());
	}
}

/**
* 课程类
**/
public class Course {
}

/**
* boss只需要通过调用teamLeader 就可以 知道最后的信息
**/
public class Test {
	public static void main(String[] args) {
		Boss boss = new Boss();
		TeamLeader teamLeader = new TeamLeader();
		boss.commandCheckNumber(teamLeader);
	}
}