设计模式01-设计模式中的七大原则

最新推荐文章于 2022-11-04 20:00:00 发布

这是自动生成的名字

最新推荐文章于 2022-11-04 20:00:00 发布

阅读量239

点赞数 1

分类专栏：设计模式

本文链接：https://blog.csdn.net/weixin_39415503/article/details/105543399

版权

设计模式专栏收录该内容

2 篇文章 0 订阅

订阅专栏

设计模式

前言

设计模式的重要性

在软件工程中，设计模式是对软件设计中普通存在（反复出现）的各种问题，所提出的解决方案；
可维护性取决于代码的可读性和规范性，如果大家都使用同一的编码规范（设计模式），那么代码的可读性和规范性就会大大提高，从而提高软件的可维护性。

设计模式在软件中哪里？

面向对象（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.为了交互对象之间的松耦合设计而努力

这是自动生成的名字

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
设计模式01-设计模式中的七大原则

1.设计模式的重要性在软件工程中，设计模式是对软件设计中普通存在（反复出现）的各种问题，所提出的解决方案；可维护性取决于代码的可读性和规范性，如果大家都使用同一的编码规范（设计模式），那么代码的可读性和规范性就会大大提高，从而提高软件的可维护性。2.设计模式在软件中哪里？面向对象（OO）=>功能模块[设计模式+数据结构与算法]=>框架[多种设计模式]=>架构[服务器集群]OOP思想指导代码风格；功能模块编码过程中，应用到设计模式和数据结构与算法等；框架是由多种设计模式构成
复制链接

扫一扫

专栏目录