一个实例用全创建型模式-优化（冗余消除）

于 2025-04-21 15:29:08 发布
阅读量1.4k 收藏 23
点赞数 67
分类专栏： 设计模式-坦克大战-java 文章标签： java 算法 前端
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/xie__jin__cheng/article/details/147395556
版权

     

1.关联链接

 上一篇：一个实例用全创建型模式-CSDN博客

目录：《一个实例讲完23种设计模式》

2.内容

当前：单件+抽象工厂+创建者+工厂方法+优化

需求：坦克大战

创建两种坦克
坦克类型     射程     速度
b70     70米     时/70公里
b50     50米     时/50公里

设计说明

1.抽象工厂承担了创建部件的任务

2.创建者承担了讲部件组装的任务

3.工厂方法类相当于创建者模式的导演，但是他是并未给用户提供选择创建者的接口。

而是通过自己的多态来实现加载不同的创建者。

类图（红色为优化的部分）

设计分析

这个需求，本质上就是对坦克描述，有两维度，级别功能是“跑”和“射击”，另一个维度是功能参数，50型号和70型号，这两个维度的结果创建不同型号的坦克。

工厂方法用于创建不同型号的坦克，工厂方法因引入不同的创建者，而可以创建不同的坦克，创建者可以创建不同的坦克因引入不同的抽象工厂不同，而创建的部件不同。创建者的两个创建步骤，创建“跑”和创建“射击”，对应抽象工厂的两个创建能力。考虑到复杂度这里没有事用享元模式，其实可以把功能静态化，比如一个具体的功能，比如“跑”这个功能对象，可以让他享元，即无论多少个坦克使用的具体跑功能对象只有一个，比如“跑”的功能，无论有多少辆坦克，跑的功能是共享的，至于70和50两个型号的差别，可以用一个参数承载。

设计模式综合运用 这个例子中就是将功能享元了。

代码

//-----基本功能部分-------------------------
//功能类
class Function{
	public String mOperation;
	public void exe(int type) {
		System.out.println(mOperation+type);
	}
};
//功能类-射击
class ShotFun extends Function{
	static ShotFun mFunction = new ShotFun();
	static ShotFun get() {
		return mFunction;
	}
	public ShotFun() {
		mOperation = "射击：";
	}
}
//功能类-跑
class RunFun extends Function{
	static RunFun mFunction = new RunFun();
	static RunFun get() {
		return mFunction;
	}
	public RunFun() {
		mOperation = "跑：";
	}
}
//-- interface 接口设计部分 ----------------
//坦克
interface ITank{
	void shot();
	void run();
	void setmShot(IOperation mShot);
	void setmRun(IOperation mRun);
}
//功能
interface IOperation{
	void exe();
}
//抽象工厂
interface IAbstractFactory{
	IOperation createShot();
	IOperation createRun();
}
//创建者模式
interface IBuilder{
	void createShout(ITank t);
	void createRun(ITank t);
}
//工厂方法
interface IFactory{
	ITank createTank();
}
//发射
abstract class Shot implements IOperation{
	int type;
	public void exe() {
		ShotFun.get().exe(type);
	}
}
//跑
abstract class Run implements IOperation{
	int type;
	public void exe() {
		RunFun.get().exe(type);
	}
}
//-----实现类-----------------------------------------------
//跑-70
class Shot70 extends Shot{
	public Shot70() {
		type = 70;
	}	
}
//跑-50
class Run70 extends Run{
	public Run70() {
		type = 70;
	}
}
//发射-70
class Shot50 extends Shot{
	public Shot50() {
		type = 50;
	}	
}
//发射-50
class Run50 extends Run{
	public Run50() {
		type = 50;
	}
}
//坦克-基类
class Tank implements ITank{
	IOperation mShot;
	IOperation mRun;
	public void setmShot(IOperation mShot) {
		this.mShot = mShot;
	}
	public void setmRun(IOperation mRun) {
		this.mRun = mRun;
	}
	public void shot() {
		mShot.exe();
	}
	public void run() {
		mRun.exe();
	}
}
//--------抽象工厂----------------------------------------------
//抽象工厂可以装机坦克的部件，但因不同工厂，创建的一系列部件型号不同
//抽象工程-实现-70
class AbstractFactory70 implements IAbstractFactory{
	public IOperation createShot() {
		return new Shot70();
	}
	public IOperation createRun() {
		return new Run70();
	}
}
//抽象工程-实现-50
class AbstractFactory50 implements IAbstractFactory{
	public IOperation createShot() {
		return new Shot50();
	}
	public IOperation createRun() {
		return new Run50();
	}
}
//-------创建者----------------
//创建者-基类
//用创建者完成坦克部件的创建，跑和设计
//同样的创建步骤，因使用不同型号的抽象工厂而使创建出的部件不同，而组装成不同型号的坦克
abstract class Builder implements IBuilder{
	IAbstractFactory mIAbstractFactory;
	public void createShout(ITank t) {
		t.setmShot(mIAbstractFactory.createShot());
	}
	public void createRun(ITank t) {
		t.setmRun(mIAbstractFactory.createRun());
	}
}
//创建者-70
class Builder70 extends Builder{
	public Builder70() {
		mIAbstractFactory = new AbstractFactory70();
	}
}
//创建者-50
class Builder50 extends Builder{
	public Builder50() {
		mIAbstractFactory = new AbstractFactory50();
	}
}
//-----工厂方法-----------------------------------
//工厂方法-基类
//就是创建坦克，因工厂不同创建的坦克就不同
//这里的不同时靠使用的创建者不同而不同
abstract class Factory implements IFactory{
	IBuilder mBuilder;
	public ITank createTank() {
		ITank t = new Tank();
		mBuilder.createRun(t);
		mBuilder.createShout(t);
		return t;
	}
}
//工厂方法-70
class Factory70 extends Factory{
	public Factory70() {
		mBuilder = new Builder70();
	}	
}
//工厂方法-50
class Factory50 extends Factory{
	public Factory50() {
		mBuilder = new Builder50();
	}
}
//--------主函数-----------------
//主函数
public class Client {
	public static void main(String[] args) {
		System.out.println("hello worldff !");
		Factory70 f7 = new Factory70();
		ITank t = f7.createTank();
		t.shot();
		t.run();
	}
}

运行结果

2.关联知识 

1.创建型模式

设计模式中的创建型模式（Creational Pattern）是一类用于处理对象创建过程的设计模式。它们旨在以灵活和高效的方式创建对象，将对象的创建过程与使用过程分离，从而降低系统的耦合度，提高代码的可维护性和可扩展性。以下是创建型模式的详细介绍：

一、创建型模式概述

创建型模式主要关注如何创建对象，它们通过封装对象的创建过程，使得客户端代码无需关心对象的创建细节，从而降低了系统的复杂度。根据《设计模式：可复用面向对象软件的基础》一书，创建型模式主要包括以下五种：

  1. 单例模式（Singleton Pattern）
  2. 工厂方法模式（Factory Method Pattern）
  3. 抽象工厂模式（Abstract Factory Pattern）
  4. 建造者模式（Builder Pattern）
  5. 原型模式（Prototype Pattern）

二、创建型模式详解

1. 单例模式（Singleton Pattern）

定义：
确保一个类只有一个实例，并提供一个全局访问点。

特点：

  • 节省内存资源，避免创建多个相同的实例。
  • 便于全局访问和控制。

应用场景：

  • 配置管理器、资源管理器等需要全局唯一实例的场景。

实现方式：

  • 饿汉式（静态初始化）：在类加载时就创建实例。
  • 懒汉式（延迟初始化）：在第一次使用时创建实例。
  • 双重检查锁定（Double-Checked Locking）：线程安全的懒汉式实现。
  • 静态内部类：利用类加载机制实现线程安全的延迟初始化。
  • 枚举（Enum）：利用枚举的特性和语法糖实现单例。

示例代码（以饿汉式为例）：

public class Singleton {
    // 类加载时就创建实例
    private static final Singleton instance = new Singleton();

    // 私有构造函数，防止外部实例化
    private Singleton() {}

    // 提供全局访问点
    public static Singleton getInstance() {
        return instance;
    }
}
2. 工厂方法模式（Factory Method Pattern）

定义：
定义一个用于创建对象的接口，但由子类决定实例化哪一个类。

特点：

  • 延迟到子类决定实例化哪一个类。
  • 遵循开闭原则，易于扩展。

应用场景：

  • 当具体类的实例化需要延迟到子类时，如日志记录器、连接池等。

实现方式：

  • 定义一个抽象工厂类，包含创建产品对象的抽象方法。
  • 子类实现抽象工厂类，提供具体的产品对象。

示例代码：

// 抽象工厂类
public abstract class Factory {
    public abstract Product createProduct();
}

// 具体工厂类
public class ConcreteFactory extends Factory {
    @Override
    public Product createProduct() {
        return new ConcreteProduct();
    }
}

// 抽象产品类
public abstract class Product {
    public abstract void use();
}

// 具体产品类
public class ConcreteProduct extends Product {
    @Override
    public void use() {
        System.out.println("Using ConcreteProduct");
    }
}
3. 抽象工厂模式（Abstract Factory Pattern）

定义：
提供一个接口，用于创建一族相关或依赖对象，而无需指定具体类。

特点：

  • 创建一族相关或依赖的对象。
  • 遵循开闭原则，易于扩展。

应用场景：

  • 系统需要一组相关或依赖的产品对象时，如UI组件的跨平台开发。

实现方式：

  • 定义一个抽象工厂类，包含创建一组相关或依赖对象的抽象方法。
  • 具体工厂类实现抽象工厂类，提供具体的产品对象。

示例代码：

// 抽象工厂类
public abstract class AbstractFactory {
    public abstract Button createButton();
    public abstract TextArea createTextArea();
}

// 具体工厂类1（Windows风格）
public class WindowsFactory extends AbstractFactory {
    @Override
    public Button createButton() {
        return new WindowsButton();
    }

    @Override
    public TextArea createTextArea() {
        return new WindowsTextArea();
    }
}

// 具体工厂类2（Mac风格）
public class MacFactory extends AbstractFactory {
    @Override
    public Button createButton() {
        return new MacButton();
    }

    @Override
    public TextArea createTextArea() {
        return new MacTextArea();
    }
}

// 抽象产品类
public abstract class Button {
    public abstract void render();
}

// 具体产品类（Windows风格按钮）
public class WindowsButton extends Button {
    @Override
    public void render() {
        System.out.println("Rendering Windows Button");
    }
}

// 具体产品类（Mac风格按钮）
public class MacButton extends Button {
    @Override
    public void render() {
        System.out.println("Rendering Mac Button");
    }
}

// 抽象产品类
public abstract class TextArea {
    public abstract void render();
}

// 具体产品类（Windows风格文本区域）
public class WindowsTextArea extends TextArea {
    @Override
    public void render() {
        System.out.println("Rendering Windows TextArea");
    }
}

// 具体产品类（Mac风格文本区域）
public class MacTextArea extends TextArea {
    @Override
    public void render() {
        System.out.println("Rendering Mac TextArea");
    }
}
4. 建造者模式（Builder Pattern）

定义：
将一个复杂对象的构建过程与其表示分离，使得同样的构建过程可以创建不同的表示。

特点：

  • 逐步构建复杂对象。
  • 便于控制构建过程，易于扩展。

应用场景：

  • 需要创建复杂对象，且对象的创建过程独立于其组成部分时，如创建复杂的文档对象。

实现方式：

  • 定义一个抽象建造者类，包含创建复杂对象各个部分的抽象方法。
  • 具体建造者类实现抽象建造者类，提供具体的产品对象。
  • 定义一个指挥者类，负责调用建造者类的方法构建复杂对象。

示例代码：

// 抽象建造者类
public abstract class Builder {
    public abstract void buildPartA();
    public abstract void buildPartB();
    public abstract Product getResult();
}

// 具体建造者类
public class ConcreteBuilder extends Builder {
    private Product product = new Product();

    @Override
    public void buildPartA() {
        product.add("PartA");
    }

    @Override
    public void buildPartB() {
        product.add("PartB");
    }

    @Override
    public Product getResult() {
        return product;
    }
}

// 产品类
public class Product {
    private List<String> parts = new ArrayList<>();

    public void add(String part) {
        parts.add(part);
    }

    public void show() {
        for (String part : parts) {
            System.out.println(part);
        }
    }
}

// 指挥者类
public class Director {
    public void construct(Builder builder) {
        builder.buildPartA();
        builder.buildPartB();
    }
}
5. 原型模式（Prototype Pattern）

定义：
通过复制现有实例来创建新对象。

特点：

  • 避免了重复初始化过程。
  • 便于创建大量相似对象。

应用场景：

  • 需要大量相似对象的场景，如编辑器中的图形工具。

实现方式：

  • 实现一个克隆方法（clone()），用于复制现有对象。

示例代码：

public class Prototype implements Cloneable {
    private String id;

    public Prototype(String id) {
        this.id = id;
    }

    public String getId() {
        return id;
    }

    // 实现克隆方法
    @Override
    protected Object clone() throws CloneNotSupportedException {
        return super.clone();
    }

    public static void main(String[] args) {
        try {
            Prototype original = new Prototype("1");
            Prototype copy = (Prototype) original.clone();
            System.out.println("Original ID: " + original.getId());
            System.out.println("Copied ID: " + copy.getId());
        } catch (CloneNotSupportedException e) {
            e.printStackTrace();
        }
    }
}

三、创建型模式总结

创建型模式通过将对象的创建过程与使用过程分离，提高了代码的灵活性和可维护性。它们适用于不同的场景，可以根据具体需求选择合适的设计模式。例如，单例模式适用于需要全局唯一实例的场景；工厂方法模式和抽象工厂模式适用于

2.创建型模式的特点 

创建型模式的特点和适用场景对比说明

创建型模式是一组处理对象创建的设计模式，它们旨在以灵活和高效的方式创建对象，将对象的创建与使用分离，提高系统的灵活性和可扩展性。以下是五种主要的创建型模式的特点和适用场景对比说明：

模式名称特点适用场景
单例模式（Singleton）1. 确保一个类只有一个实例，并提供一个全局访问点。1. 需要确保一个类只有一个实例的场景，如配置管理器、资源管理器等。
2. 节省系统资源，避免重复创建对象。2. 需要全局访问点的场景，如全局状态管理器、全局配置对象等。
3. 实现简单，但需注意多线程环境下的安全性。3. 对象创建开销较大的场景，避免重复初始化。
工厂方法模式（Factory Method）1. 定义一个创建对象的接口，由子类决定实例化哪一个类。1. 需要根据条件动态选择不同产品类的场景，如日志记录器、连接池等。
2. 延迟对象的创建到子类，符合开闭原则。2. 需要创建不同类型的对象，而客户端不需要知道具体实现类的场景。
3. 提高了系统的灵活性和可扩展性。3. 需要在不修改客户端代码的情况下，通过扩展子类支持新产品的场景。
抽象工厂模式（Abstract Factory）1. 提供一个接口，用于创建一族相关或依赖对象，而无需指定具体类。1. 需要创建一组相互关联或相互依赖的对象，如UI组件的跨平台开发。
2. 隔离了具体类的生成，使得客户并不需要知道什么被创建。2. 需要支持多种产品族，并且希望这些产品族的创建能够被封装起来的场景。
3. 增加或替换产品族比较方便，支持开闭原则。3. 系统需要独立于具体产品的创建、组合和表示时。
建造者模式（Builder）1. 将一个复杂对象的构建过程与其表示分离，逐步构造对象。1. 需要创建复杂对象，且对象的创建过程独立于其组成部分时，如创建复杂的文档对象。
2. 可以创建不同表示的对象，实现产品的灵活创建。2. 需要构建过程允许对象有不同的表示时。
3. 客户端不必知道产品内部组成的细节。3. 构建过程需要精细控制，允许分步构建和组装对象。
原型模式（Prototype）1. 通过复制现有实例来创建新对象，避免重复初始化。1. 需要大量相似对象的场景，如编辑器中的图形工具。
2. 提高了对象的创建效率，简化了创建过程。2. 创建对象的成本较高，或对象初始化过程较复杂的场景。
3. 支持对象的深拷贝和浅拷贝。3. 需要通过复制现有对象来创建新对象时。

详细对比说明：

  1. 单例模式：

    • 特点：单例模式确保一个类只有一个实例，并提供一个全局访问点。它常用于需要全局控制资源的场景，如配置管理、日志记录、数据库连接等。
    • 适用场景：
      • 当需要确保在整个应用程序中某个类只能存在一个实例时。
      • 当对象需要被共享的场合，共享对象可以节省内存，并加快对象访问速度。
      • 当某类需要频繁实例化，而创建的对象又频繁被销毁时。

  2. 工厂方法模式：

    • 特点：工厂方法模式定义一个创建对象的接口，由子类决定实例化哪一个类。它将对象的创建过程延迟到子类，符合开闭原则，提高了系统的灵活性和可扩展性。
    • 适用场景：
      • 当需要创建不同类型的对象，而客户端不需要知道具体实现类的场景。
      • 当需要根据条件动态选择不同产品类的场景。
      • 当需要在不修改客户端代码的情况下，通过扩展子类支持新产品的场景。

  3. 抽象工厂模式：

    • 特点：抽象工厂模式提供一个接口，用于创建一族相关或依赖对象，而无需指定具体类。它隔离了具体类的生成，使得客户并不需要知道什么被创建，支持开闭原则。
    • 适用场景：
      • 当需要创建一组相互关联或相互依赖的对象时。
      • 当需要支持多种产品族，并且希望这些产品族的创建能够被封装起来的场景。
      • 当系统需要独立于具体产品的创建、组合和表示时。

  4. 建造者模式：

    • 特点：建造者模式将一个复杂对象的构建过程与其表示分离，逐步构造对象。它允许通过指定复杂对象的类型和内容逐步构造一个复杂对象，客户端不必知道产品内部组成的细节。
    • 适用场景：
      • 当需要创建复杂对象，且对象的创建过程独立于其组成部分时。
      • 当构建过程需要精细控制，允许分步构建和组装对象时。
      • 当需要创建不同表示的对象，实现产品的灵活创建时。

  5. 原型模式：

    • 特点：原型模式通过复制现有实例来创建新对象，避免重复初始化。它提高了对象的创建效率，简化了创建过程，支持对象的深拷贝和浅拷贝。
    • 适用场景：
      • 当需要大量相似对象的场景。
      • 当创建对象的成本较高，或对象初始化过程较复杂的场景。
      • 当需要通过复制现有对象来创建新对象时。

总结：

创建型模式通过封装对象的创建方式，使得系统不依赖于具体的类，实现了对象创建的抽象化和多样化。在选择使用哪种创建型模式时，需要根据具体的需求和上下文，考虑对象的创建过程、系统的灵活性和可扩展性等因素。

3.创建型模式的特点

以下是对创建型模式的特点和使用场景的对比说明，使用表格形式展示：

创建型模式特点使用场景
单例模式- 确保一个类只有一个实例，并提供一个全局访问点。- 当需要确保在整个应用程序中某个类只能存在一个实例时，例如配置管理器、连接池等。
工厂方法模式- 定义一个创建对象的接口，但由子类决定实例化哪一个类。工厂方法让类的实例化推迟到子类中进行。- 当需要一个类对象的创建逻辑，但希望由子类来决定实例化哪一个类时，例如日志记录器、连接池等。
抽象工厂模式- 提供一个接口，用于创建一系列相关或依赖对象的家族，而不需要指定它们的具体类。- 当需要一个系列的相互依赖或相互关联的对象，并且希望这些对象的创建能够被封装起来时，例如UI组件的跨平台开发。
建造者模式- 将复杂对象的构建和表示分离，允许通过指定复杂对象的类型和内容逐步构造一个复杂对象。- 当需要创建一个包含多个组成部分的复杂对象，并且希望这些组成部分可以独立变化时，例如创建复杂的文档对象。
原型模式- 通过复制现有的实例来创建新的实例，而不是通过实例化一个类。- 当创建对象的成本很高，或者希望使用一个对象作为原型来创建更多相似对象时，例如编辑器中的图形工具。

说明：

  • 单例模式：适用于需要全局唯一实例的场景，如配置文件管理器、数据库连接池等。通过确保一个类只有一个实例，可以节省系统资源，并简化对共享资源的访问。

  • 工厂方法模式：适用于需要延迟到子类决定实例化哪一个类的场景。通过定义一个创建对象的接口，将对象的创建逻辑封装在子类中，提高了系统的可扩展性和灵活性。

  • 抽象工厂模式：适用于需要创建一系列相关或依赖对象的场景。通过提供一个接口来创建一组相关对象，使得客户端不需要关心具体实现，只需关心接口即可。

  • 建造者模式：适用于需要构建复杂对象的场景。通过分离对象的构建过程和表示，可以逐步构造一个复杂对象，并允许在构建过程中改变对象的表示。

  • 原型模式：适用于需要快速创建大量相似对象的场景。通过复制现有对象来创建新对象，可以节省创建时间，并提高对象的创建效率。

这些创建型模式在软件开发中各有优势，可以根据具体需求选择合适的设计模式来提高代码的可维护性、可扩展性和重用性。

4.模式渊源分析 

一 模式分析表（桥接6模式）

桥接模式和桥接模式衍生的模式都是应用非常广泛的模式，我认为是学习的重点。

模式名称桥接对象桥接数桥接属性桥接图形桥接迭代
1装饰 自己单个静态链表有
2组合自己多个静态树（图）有
3观察者观察者多个静态点没
4职责链职责者单个静态链表有
5策略策略者单个动态点没
6状态状态者单个动态点没
7解释器解释器多个静态图有

概念解释

桥接对象：桥接的对象

桥接数：桥接关系发生桥接对象的数量

桥接属性：这个桥接使动态还是静态的，比如状态模式中的状态桥接是不断的变化的，而组合模式的桥接，在桥接后就不会发生变化，桥接的关系会固定下来所以是静态的。

桥接图形：桥接关系形成的最终图形，装饰会形成一个装饰链。组合会形成一种图的结构。观察者因为桥接的是一个链表型的观察者，会形成链表，但是这个链表不是有桥接关系形成，桥接关系只形成了一个点。

桥接迭代：指桥接关系是否发生迭代。

二 中间件4模式

   通用意图：承载关联，隔离关联，减少关联

序号名称代理的连接各自特性
1适配器类（桥接）是解决接口不匹配的问题，有可能是一系列的接口
2外观类（桥接）将内部公共函数代理，对外部模块公开。消除外部模块的直接访问，减少了外部模块和内部个模块的连接。如果在更大一层的空间考虑。这个外观，也可以当做中介者。
3代理类（桥接）这个外观的差别不大，不过这个模式强调的不是减少关联，而是一个保护层，举个例子说，这个层可能比外观更外一层，对一些非亲近的模块执行一些访问接口的限制。这层的主要价值在于权限的控制。
4中介者函数（依赖）

该模块的主要价值体系在对内部依赖级别的关系消除。不紧密的几个类之间有调用关系，或者几个类简单调用关系较少，可以用一个中介者还承担这些相互的调用，从而消除一些耦合，使他们只和中介者发生耦合。他的特点与外观相比，更大的 针对性，在内部，且他是对几个平行关系者的代理。而外观是一个模块公布初期的接口，是对外提供。虽然从结构的本质上没发做绝对的区分。但是使用意图是不一样的。

结构关系和价值是一样的。

但这不重要，举个例子吧，如果AF,是A模块的外观，复杂和BF和CF沟通，那么在A BF,CF间，他就相当于中介者。

不饶了，我想您应该理解了吧

二 模式分析表（其他模式）

名称模板迭代接口性能分类
1迭代器有多专用5模式
2模板有多专用5模式
3命令有单专用5模式
4备忘录多专用5模式
5解释器单专用5模式
6单件单创建型模式
7抽象工厂有多创建型模式
8工厂方法单创建型模式
9创建者多创建型模式
10原型单有创建型模式
11享元单有创建型模式
12访问者单双向依赖模式

5.面向对象五关系深入分析 

 五种关系：
一般化关系、关联关系、聚合关系、合成关系、依赖关系。

一般化关系（Generalization）
表示类与类之间的继承关系，接口与接口之间的继承关系，或类对接口的实现关系。

关联关系（Association）
是类与类之间的联接，它使一个类知道另一个类的属性和方法。可以单向和双向。

聚合关系（Aggregation）
关联关系的一种，是强关联关系。表示整体和个体之间的关系。

合成关系（Composition）
关联关系的一种。比聚合关系更强。要求整体对象负责部分对象的生命周期。

依赖关系（Dependency）
类与类之间的联接，单向。表示一个类依赖于另一个类的定义。

关系图

为什么化这样是一个图呢，因为我觉得，这五种关系是升级的关系。

也及是说：如果是聚会关系了，一定已经包含链接关系了，如果已经是链接关系了，那么不可能没有依赖关系

定义关系调用关系后于自己创建生命周期相同先于自己创建
依赖关系A(B b)
链接关系A(B b)A{ b.fun()}
聚会关系A(B b)A{ b.fun()}

A{ B mb=null }

合成关系A(B b)A{ b.fun()}A{ B mb=null }A{ B mb=new B() }
继承关系

A(B b)

b=super

A{ b.fun()}

b = super

A{ B mb=null }

b = super

A{ B mb=new B() }

b = super

super(B).fun()

b = super

上面这表是从升级的角度对5种关系做了一下分析。

我不多说的，应该很容易理解。

但是在分析这个的过程中我 有发现了一个问题

A对B依赖的升级和生命周期的关系

定义关系：A先于B

调用关系：A先于B

聚合关系：A先于B

组合关系：A==B

继承关系：B先于A

有A对于B升级的依赖我们发现，关系越高越靠得住。

这也说明了，为什么设计时候几乎不用刻意的消除“聚会关系”关系以上的关系呢。

其实就从人与人之间的关系考虑，也是的，关系密切到一定的程度，关系反而简单了。

就这里聚合以上的关系我这里把他暂时定义为亲人的关系。

在亲人这个关系内处理问题是相对简单的，多密切都不会增加复杂度。

而链接和依赖这不同，因为可靠性降低了，所以导致了很多不确定性。

就社会而言，整个社会的复杂度增加也是在这个层面上。

那么这里我想，是不是觉得事情是否复杂的不是耦合度，而是可靠性？

这里暂时一想：我还没有深入的考虑这个问题。

评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值