设计模式01-设计模式中的七大原则
设计模式
目录
- 设计模式
- 前言
- 设计模式的重要性
- 设计模式在软件中哪里？
- 正文
- 1.设计模式的目的
- 2.设计模式七大原则（设计模式的设计依据，开发人员应该遵循的规则）
- 1.单一职责原则 Single Response Principle,SRP
- 2.接口隔离原则 Interface Segregation Principle,ISP
- 3.依赖倒置原则 Dependence Inversion Principle,DIP
- 4.里氏替换原则 Liskov Substitution Priciple,LSP
- 5.开闭原则 Open Closed Priciple,OCP
- 6.迪米特法则 Demter Principle,DP
- 7.合成复用原则 Composite Reuse Principle,CSP
- 8.七大设计原则的简单总结 Simple Summary
前言
设计模式的重要性
在软件工程中，设计模式是对软件设计中普通存在（反复出现）的各种问题，所提出的解决方案；
可维护性取决于代码的可读性和规范性，如果大家都使用同一的编码规范（设计模式），那么代码的可读性和规范性就会大大提高，从而提高软件的可维护性。
设计模式在软件中哪里？
面向对象（OO）=>功能模块[设计模式+数据结构与算法]=>框架[多种设计模式]=>架构[服务器集群]
OOP思想指导代码风格；功能模块编码过程中，应用到设计模式和数据结构与算法等；框架是由多种设计模式构成的；而框架又构成架构；
正文
1.设计模式的目的
设计模式是为了让程序（软件），具有更好的代码重用性、可读性、可扩展性、可靠性和使程序呈现高内聚，低耦合的特性
代码重用性：相同功能的代码，一次编写，多次使用。
代码可读性：遵循某种编程规范，便于其他开发人员的阅读和理解。
可扩展性： 在对现有系统影响最小的情况下，提高系统功能的可持续扩展和提升的能力。
可靠性：当对系统进行功能增加，对原有的系统功能产生最少的影响或没有影响。
高内聚：一个软件模块是由相关性很强的代码组成，只负责一项任务，也就是常说的单一责任原则。
低耦合：模块与模块之间的关联性弱，模块的独立性强
2.设计模式七大原则（设计模式的设计依据，开发人员应该遵循的规则）
我们在使用设计模式的时候要遵循七大原则，分别是:
1.单一职责原则 Single Response Principle,SRP
在类的角度而言，一个类应该只负责一项职责，同时单一职责原则也能应用在方法级别上，道理同上；
e.g. 如class A有两个不同的职责：职责1和职责2；当职责1的需求变更时，那么class A就需要作出改变，而改变A的同时，有可能会导致职责2的执行错误；
所以我们需要将class A分解成两个类：A1,A2,分别单独负责职责1和职责2
以下是实验代码，逐层递进
package demo01.SingleResPrinciple;
public class SingleResponsePrinciple {
public static void main(String[] args) {
Vehicle vehicle = new Vehicle();
vehicle.run("三轮车");
vehicle.run("小轿车");
vehicle.run("单车");
}
}
//交通工具类
/**
* 方案1：
* 1.在方案1的run方法中，违反了单一职责原则
* 解决方案：根据交通工具运行场景不同，分解成若干个负责单独职责的类
*/
class Vehicle{
public void run(String vehicle){
System.out.println(vehicle+" 在公路上跑....");
}
}
方案2：对方案1的改进
package demo01.SingleResPrinciple;
public class SingleResponsePrinciple02 {
public static void main(String[] args) {
SuperVehicle road = new RoadVehicle();
road.run("摩托");
SuperVehicle sky = new SkyVehicle();
sky.run("C919大客机");
}
}
/**
* 方案2：
* 1.遵循了单一职责原则
* 2.但这种方式改动很大（有时候代价大），即：将类分解，要同时修改C/S两端
* 改进方案：直接修改Vehicle类，改变的代码会比较少=>方案3（方法级别上的单一职责原则）
*/
interface SuperVehicle{
public void run(String vehicle);
}
class RoadVehicle implements SuperVehicle{
public void run(String vehicle){
System.out.println(vehicle+" 在公路上运行");
}
}
class SkyVehicle implements SuperVehicle{
public void run(String vehicle){
System.out.println(vehicle+" 在天上上运行");
}
}
class SeaVehicle implements SuperVehicle{
public void run(String vehicle){
System.out.println(vehicle+" 在海洋中运行");
}
}
方案3：在面对系统花销，修改代价上一定程度的妥协（慎用）
package demo01.SingleResPrinciple;
public class SingleResponsePrinciple03 {
public static void main(String[] args) {
Vehicle2 vehicle2 = new Vehicle2();
vehicle2.run("摩托");
vehicle2.runSky("C919大客机");
vehicle2.runSea("铁达呢号");
}
}
/**
* 方案3：
* 1.这个方案没有对原来的类作较大的修改，仅新增了方法
* 2.这里虽然没有在类级别上颜色遵守单一职责原则；但在方法级别上，遵循了单一职责原则。
*/
class Vehicle2{
public void run(String vehicle){
System.out.println(vehicle +" 在公路上跑");
}
public void runSky(String vehicle){
System.out.println(vehicle+" 在天空飞");
}
public void runSea(String vehicle){
System.out.println(vehicle+" 在海洋航行");
}
}
总结：单一职责原则注意事项和细节
1.降低类的复杂度，一个类只负责一个任务（职责）
2.提高类的可读性，可维护性
3.降低需求变更引发的风险
4.通常情况下，我们应当尽量遵循类的单一职责原则；只有在逻辑足够简单，类中方法数量足够少，才能选择在方法级别上遵循单一职责原则（减少系统花销）；否则，请遵守类级别的单一职责原则，将一个类拆分成若干个类，它们分别负责每一个单一职责（任务）；
2.接口隔离原则 Interface Segregation Principle,ISP
概念：一个类对另一个类的依赖，往往是通过接口来实现的。所以一个类对另外一个类的依赖性应当是建立在最小的接口上的。使用多个专门的接口比使用单一的总接口要好。 即将一个大的接口拆成若干个小的接口。
让我们在案例中理解
现在我们有这样的需求：类A、类C需要通过接口依赖类B和类D
按照UML图，我们有以下代码
package demo01.Demo02_IntefaceSegraPriciple;
public class Segreagion1 {
public static void main(String[] args) {
//A、C通过接口去依赖B、D
//这违反了接口隔离原则，因为A、C只需要一部分的方法；
A a = new A();
a.depend1(new B());
C c = new C();
c.depend4(new D());
}
}
interface Interface1{
void operation1();
void operation2();
void operation3();
void operation4();
void operation5();
}
class B implements Interface1 {
public void operation1() {
System.out.println("B implements operation1");
}
public void operation2() {
System.out.println("B implements operation2");
}
public void operation3() {
System.out.println("B implements operation3");
}
public void operation4() {
System.out.println("B implements operation4");
}
public void operation5() {
System.out.println("B implements operation5");
}
}
class D implements Interface1 {
public void operation1() {
System.out.println("D implements operation1");
}
public void operation2() {
System.out.println("D implements operation2");
}
public void operation3() {
System.out.println("D implements operation3");
}
public void operation4() {
System.out.println("D implements operation4");
}
public void operation5() {
System.out.println("D implements operation5");
}
}
class A{//class A通过接口Interface1 依赖（使用）B类，但是只会用到1,2,3方法
public void depend1( Interface1 i){//在这，类A对接口依赖存在冗余
i.operation1();
}
public void depend2( Interface1 i){
i.operation2();
}
public void depend3( Interface1 i){
i.operation3();
}
}
class C{//class C通过接口Interface1 依赖（使用）D类，但是只会用到1,4,5方法
public void depend1( Interface1 i){//在这，类C对接口依赖存在冗余
i.operation1();
}
public void depend4( Interface1 i){
i.operation4();
}
public void depend5( Interface1 i){
i.operation5();
}
}
上述方案1违反了接口隔离原则。虽然最后实现了A、C对B、D的依赖。但是A、C对接口依赖显然存在冗余，在Java编程中，这是不符合规范的，会带来潜在未知的风险。
于是我们有了下面的代码和UML分析图
根据需求和ISP原则，将接口Interface1拆分为独立的几个接口，类A和类C分别与它们所需要的接口建立依赖关系；即采用接口隔离原则
接口Interface1中出现的方法，根据实际情况拆分为三个接口
package demo01.Demo02_IntefaceSegraPriciple.improve;
//此案例遵循了接口隔离原则
public class Segreagion2 {
public static void main(String[] args) {
A a = new A();
a.depend1(new B());
a.depend2(new B());
a.depend3(new B());
C c = new C();
c.depend1(new D());
c.depend4(new D());
c.depend5(new D());
}
}
interface Interface1{
void operation1();
}
interface Interface2{
void operation2();
void operation3();
}
interface Interface3{
void operation4();
void operation5();
}
class B implements Interface1,Interface2{
public void operation1() {
System.out.println("B implements operation1");
}
public void operation2() {
System.out.println("B implements operation2");
}
public void operation3() {
System.out.println("B implements operation3");
}
}
class D implements Interface1,Interface3{
public void operation1() {
System.out.println("D implements operation1");
}
public void operation4() {
System.out.println("D implements operation4");
}
public void operation5() {
System.out.println("D implements operation5");
}
}
class A{//class A通过接口Interface1,Interface2 依赖（使用）B类，方法1,2,3都在；不多不少刚刚好
public void depend1(Interface1 i){
i.operation1();
}
public void depend2(Interface2 i){
i.operation2();
}
public void depend3(Interface2 i){
i.operation3();
}
}
class C{//class C通过接口Interface1,Interface3 依赖（使用）D类，方法1,4,5都有；不多不少刚刚好
public void depend1(Interface1 i){
i.operation1();
}
public void depend4(Interface3 i){
i.operation4();
}
public void depend5(Interface3 i){
i.operation5();
}
}
3.依赖倒置原则 Dependence Inversion Principle,DIP
1.高层模块不应该依赖底层模块，二者都应该依赖其抽象
2.抽象不应该依赖细节，细节应该依赖抽象（具体类（方法）要依赖接口）
3.依赖倒置的中心思想是面向接口编程
4.依赖倒置原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多。
以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。
在java中，抽象指的是接口或抽象类，细节就是具体的实现。
5.使用接口或抽象类的目的是指定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。
下面我们用案例来描述：
package demo01.Demo03_Iversion;
public class DependecyInversion {
public static void main(String[] args) {
Person person = new Person();
person.receive(new Email());
}
}
class Email{
public String getInfo(){return "电子邮件信息：hello,world";}
}
//完成person接收消息的功能
/**
* 方式1分析
* 1.简单，比较容易想到
* 2.如果我们获取的对象是 微信，短信等，则新增类，同时Person也要增加相应的接收方法，这样扩展性差
* 3.解决思路：引入一个抽象的接口IReceiver,表示接收者，这样Person类与接口发生依赖
* 因为Email，Wechat 等等都属于接收的范畴，他们各自实现IReceiver就ok了，这样就符合依赖倒置原则
*/
class Person{
public void receive(Email email){//这里是直接依赖具体细节（具体类）
System.out.println(email.getInfo());
}
}
通过方案1我们可以看到，有明显的依赖细节，不符合依赖倒置原则；于是有了方案2
package demo01.Demo03_Iversion.improve;
public class DependecyInversion {
public static void main(String[] args) {
//客户端无需改变
Person person = new Person();
person.receive(new Email());
person.receive(new Wechat());
}
}
//定义接口
interface IReceiver{
public String getInfo();
}
class Email implements IReceiver{
public String getInfo(){return "电子邮件信息：hello,world";}
}
class Wechat implements IReceiver{
public String getInfo(){return "微信信息：hello,world";}
}
//完成person接收消息的功能
class Person{
public void receive(IReceiver receiver){//这里我们是对接口实现依赖
System.out.println(receiver.getInfo());
}
}
在依赖倒置时，往往会发生依赖关系传递，依赖关系传递有主要有三种方式
1.构造器
2.接口
3.setter方法
以下是实验代码
package demo01.Demo03_Iversion.improve;
//依赖关系传递的三种方式
public class DependecyInversion2 {
public static void main(String[] args) {
}
}
/**
* 方式1.通过接口传递依赖
* 开关的接口
*/
//interface IOpenAndClose{
// public void open(ITV tv);//抽象方法，接收接口
//}
//interface ITV{//ITV接口
// public void play();
//}
实现接口
//class OpenAndClose implements IOpenAndClose{
// public void open(ITV tv) {
// tv.play();
// }
//}
/**
* 方式2：通过构造方法传递依赖
*/
//interface IOpenAndClode{
// public void open();//抽象方法
//}
//interface ITV{
// public void play();
//}
//class OpenAndClose implements IOpenAndClode{
// public ITV tv;//成员
// public OpenAndClose(ITV tv){//通过构造器传递参数
// this.tv=tv;
// }
// public void open() {
// this.tv.play();
// }
//}
/**
* 方式3.通过setter方传递依赖
*/
interface IOpenAndClode{
public void open();//抽象方法
public void setTV(ITV tv);
}
interface ITV{//ITV接口
public void play();
}
class OpenAndClose implements IOpenAndClode{
public ITV tv;//成员
public void setTV(ITV tv) {//通过set的方式传递依赖
this.tv=tv;
}
public void open() {
this.tv.play();
}
}
4.里氏替换原则 Liskov Substitution Priciple,LSP
LSP告诉我们继承要遵循的规则
继承的利弊：
1.继承包含这样的一层含义：父类凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类都必须遵循这些契约，
但是如果子类对这些已经实现的方法任意进行任意修改，可能会对整个继承体系造成破坏。
2.继承在给程序带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低；如果一个类被其他的类所继承，
当这个类需要修改的时候，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能发生故障
里氏原则：
1.如果对每个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的程序P在所有的对象o1都代换成o2是，程序的行为都没有发生变化。
那么类型T2就是类型T1的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象
2.在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法
3.里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合、组合、依赖来解决问题。
以下是实验代码
方案1
package demo01.demo04_Liskvo;
public class Liskvo {
public static void main(String[] args) {
A a = new A();
System.out.println("11 -3 = "+a.func1(11,3));
B b = new B();
System.out.println("11-3 = "+b.func1(11,3));
}
}
//A类
class A{
public int func1(int n1,int n2){
return n1-n2;
}
}
//B类继承了A
//增加了一个新功能：完成两个数相加，然后和9求和
class B extends A{
//这里，重写了A类的方法，可能是无意识的
public int func1(int n1,int n2){
return n1+n2;
}
public int func2(int n1,int n2){
return func1(n1,n2)+9;
}
}
方案2.
里氏替换原则告诉我们：原来的原来和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖、聚合、组合等关系替代继承。
package demo01.demo04_Liskvo.improve;
/*
里氏替换原则告诉我们：原来的福来和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖、聚合、组合等关系替代继承。
*/
public class Liskvo {
public static void main(String[] args) {
A a = new A();
System.out.println("11 -3 = "+a.func1(11,3));
B b = new B();
//因为B类不再继承A类，因此调用者不会再认为func1是求减法了
//调用完成的功能就会很明确
System.out.println("10+3 = "+b.func1(10,3));
//通过组合仍然可以使用到A类的相关方法
System.out.println("11-3 = "+b.func3(11,3));
}
}
//创建一个更加基础的基类
class Base{
//把更加基础的方法和成员写到Base类中
}
//A类继承Base
class A extends Base{
public int func1(int n1,int n2){
return n1-n2;
}
}
//B类也继承Base
//增加了一个新功能：完成两个数相加，然后和9求和
class B extends Base {
//如果B需要使用A类的方法，使用组合关系
private A a =new A();//这里是组合关系
public int func1(int n1,int n2){
return n1+n2;
}
public int func2(int n1,int n2){
return func1(n1,n2)+9;
}
//我们仍然想使用A的方法
public int func3(int n1,int n2){
return this.a.func1(n1,n2);//这里通过组合关系使用A类的方法
}
}
5.开闭原则 Open Closed Priciple,OCP
1.OCP是编程中最基础，最重要的设计原则
2.一个软件实体如类，模块和函数应该对扩展开放（对提供方），对修改关闭（使用方）。用抽象构建框架，用实现扩展细节。
3.当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。（只增加代码，不修改代码）
4.编程中遵循其他原则，以及使用设计模式的目的就是遵循开闭原则。
以下是实验代码
package demo01.demo05_openClosed;
/**
* 方案1.
* 1.优点是简单明了
* 2.缺点了违反了设计原则的ocp原则，即对扩展开放，对修改关闭
* 3.比如我们要新增一个图形种类（三角形），需要修改的代码很多
*/
public class Ocp {
public static void main(String[] args) {
//使用看看存在的问题
GraphicEditor graphicEditor = new GraphicEditor();
graphicEditor.drawShape(new Circle());
graphicEditor.drawRectangle(new Rectangle());
graphicEditor.drawTriangle(new Triangle());//使用新增的三角形
}
}
//这是一个用于绘图的类【使用方】
class GraphicEditor{
//接收Shape对象，然后根据type，来绘制不同的图形
public void drawShape(Shape s){
if (s.m_type ==1)
drawRectangle(s);
else if(s.m_type==2)
drawCircle(s);
else if(s.m_type==3)
drawTriangle(s);
}
public void drawRectangle(Shape r){
System.out.println(" 矩形 ");
}
public void drawCircle(Shape r){
System.out.println(" 圆形 ");
}
//新增的绘制三角形
public void drawTriangle(Shape r){
System.out.println(" 三角形 ");
}
}
//Shape类，基类
class Shape{
int m_type;
}
class Rectangle extends Shape{
Rectangle(){
super.m_type=1;
}
}
class Circle extends Shape{
Circle(){
super.m_type=2;
}
}
//新增的三角形
class Triangle extends Shape{
Triangle(){
super.m_type=3;
}
}
上述代码问题很大，一旦要新增功能，则几乎所有地方都要修改。
以下是改进方案
package demo01.demo05_openClosed.improve;
/**
改进方案1的思路：
把创建Shape类做成抽象类，并提供一个抽象的draw方法，让子类去实现即可，这样我们有新的图形种类时，
只需要让新的图形类继承Shape，并实现draw方法即可
这样使用方的代码就不用修改了
*/
public class Ocp {
public static void main(String[] args) {
GraphicEditor graphicEditor = new GraphicEditor();
graphicEditor.drawShape(new Circle());
}
}
//这是一个用于绘图的类【使用方】
class GraphicEditor{
public void drawShape(Shape s){//接收一个抽象类，细节由子类实现
s.draw();
}
}
//Shape类，基类，抽象类
abstract class Shape{
int m_type;
public void draw(){};
}
class Rectangle extends Shape {
public void draw(){
System.out.println(" 矩形 ");
}
}
class Circle extends Shape {
public void draw(){
System.out.println(" 圆形 ");
}
}
//新增的三角形
class Triangle extends Shape {
public void draw(){
System.out.println(" 三角形 ");
}
}
6.迪米特法则 Demter Principle,DP
1.一个对象应该对其他对象保持最少的了解
2.类与类的关系越密切，耦合度越大
3.迪米特法则(Demter Principle)又叫 最少知道原则 ，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public方法，不对外泄露任何信息
4.DP还有一个更简单的定义：只与直接的朋友通信
5.直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象有耦合关系，我们就说着两个对象之间是朋友关系。耦合的方式有很多种：依赖、关联、组合、聚合等。其中我们称出现成员变量、方法参数、方法返回值的类为直接的朋友；而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。
总结：
1.DP核心是降低类之间的耦合
2.但是注意：由于每个类都减少了不必要的依赖，因此DP知识要求降低类之间（对象间）耦合度，并不是要求完全没有关系。
用案例来说明DP
以下是实验代码，方案1没有遵循DP
package demo01.demo06_Demter;
import java.util.ArrayList;
import java.util.List;
//客户端
public class Demter1 {
public static void main(String[] args) {
//创建一个SchoolManager 对象
SchoolManager schoolManager = new SchoolManager();
//输出学院的员工id 和 学校总部的员工信息
schoolManager.printAllEmployee(new CollegeManager());
}
}
//学校总部员工类
class Employee{
private String id;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
}
//学院的员工
class CollegeEmployee{
private String id;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
}
//管理学院员工的类
class CollegeManager{
//返回学院的所有员工
public List<CollegeEmployee> getAllEmployee(){
ArrayList<CollegeEmployee> list = new ArrayList<CollegeEmployee>();
for (int i = 0; i < 10; i++) {//这里增加了10个员工到list集合
CollegeEmployee emp = new CollegeEmployee();
emp.setId("学院员工id= "+i);
list.add(emp);
}
return list;
}
}
//学校的管理类
/*
* 分析SchoolManager 类的直接朋友有哪些 ？ Employee ，CollegeManager
*
*
*
* CollegeEmployee 不是直接朋友，而是陌生类，违反了迪米特法则
*
*
* */
class SchoolManager{
//返回学校总部的员工
public List<Employee> getAllEmployee(){
ArrayList<Employee> list = new ArrayList<Employee>();
for (int i = 0; i < 5; i++) {//增加了5个员工到list集合
Employee emp = new Employee();
emp.setId("学校的员工id= "+i);
list.add(emp);
}
return list;
}
//该方法完成输出学校总部和学院员工信息（id）
void printAllEmployee(CollegeManager sub){
//分析问题
//1.这里的CollegeEmployee 不是 SchoolManager的直接朋友
//2.CollegeEmployee 是以局部变量方式出现在 SchoolManager中
//获取到学院员工
List<CollegeEmployee> list1 = sub.getAllEmployee();
System.out.println("------------学院员工------------");
for (CollegeEmployee e : list1) {
System.out.println(e.getId());
}
//获取到学校总部员工
System.out.println("------------学校总部员工----------------");
List<Employee> list2 = this.getAllEmployee();
for (Employee e : list2) {
System.out.println(e.getId());
}
}
}
以下是改进代码，方案2
package demo01.demo06_Demter.improve;
import java.util.ArrayList;
import java.util.List;
//客户端
public class Demter1 {
public static void main(String[] args) {
System.out.println("使用迪米特法则的改进");
//创建一个SchoolManager 对象
SchoolManager schoolManager = new SchoolManager();
//输出学院的员工id 和 学校总部的员工信息
schoolManager.printAllEmployee(new CollegeManager());
}
}
//学校总部员工类
class Employee{
private String id;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
}
//学院的员工
class CollegeEmployee{
private String id;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
}
//管理学院员工的类
class CollegeManager{
//返回学院的所有员工
public List<CollegeEmployee> getAllEmployee(){
ArrayList<CollegeEmployee> list = new ArrayList<CollegeEmployee>();
for (int i = 0; i < 10; i++) {//这里增加了10个员工到list集合
CollegeEmployee emp = new CollegeEmployee();
emp.setId("学院员工id= "+i);
list.add(emp);
}
return list;
}
//输出学院员工的信息
public void printEmployee(){
//获取到学院员工
List<CollegeEmployee> list1 = this.getAllEmployee();
System.out.println("------------学院员工------------");
for (CollegeEmployee e : list1) {
System.out.println(e.getId());
}
}
}
//学校的管理类
/*
* 分析SchoolManager 类的直接朋友有哪些 ？ Employee ，CollegeManager
*
*
*
* CollegeEmployee 不是直接朋友，而是陌生类，违反了迪米特法则
*
*
* */
class SchoolManager{
//返回学校总部的员工
public List<Employee> getAllEmployee(){
ArrayList<Employee> list = new ArrayList<Employee>();
for (int i = 0; i < 5; i++) {//增加了5个员工到list集合
Employee emp = new Employee();
emp.setId("学校的员工id= "+i);
list.add(emp);
}
return list;
}
//该方法完成输出学校总部和学院员工信息（id）
void printAllEmployee(CollegeManager sub){
//分析问题
//1.将输出学院员工的方法，封装到CollegeManager中
sub.printEmployee();
//获取到学校总部员工
System.out.println("------------学校总部员工----------------");
List<Employee> list2 = this.getAllEmployee();
for (Employee e : list2) {
System.out.println(e.getId());
}
}
}
7.合成复用原则 Composite Reuse Principle,CSP
原则是尽量使用合成/聚合的方式，而不是使用继承。
用图来说明
继承的耦合性太强了，推荐使用其他几种方式来实现调用
8.七大设计原则的简单总结 Simple Summary
1.找出应用中可能需要变化之处，把它们独立起来，不要和那些不需要变化的代码混在一起
2.针对接口编程，而不是针对实现编程
3.为了交互对象之间的松耦合设计而努力