设计模式笔记搬运

119 阅读4分钟

之前看图解设设计模式的一些笔记

Factory Method 把实例的生成交给子类
角色
framework:
Prooduct 产品的抽象类
Creator 创建者
ConcreteProduct 产品
ConcreteCreator 具体的生产工厂

product内有三个方法
1.生产实例的 createProduct abstract
2.注册实例的 registerProduct abstract
3.写好的生产过程 create
注册实例是个新鲜事 在具体的里面把生产过的实例记录

Adapter 适配器模式
角色:
Target(对象)
所要用的工具类或者接口也可以,被请求者熟知的工具
Client(请求者)
具体使用的一方
Adapter(适配器)
实现Target中需求的类
Adaptee(被适配的对象)
真正的,原始的 真正干活的类
实现了不更改 被适配对象Adaptee 的对外的接口,不更改请求者的使用习惯
将两者连接起来

java.util.Properties

Template Method 把具体处理交给子类
角色:
AbstrateClass(抽象类)
其中定义了 原子操作的名称 具体操作(或者叫做算法)的流程
ConcreteClass(具体类)
实现了 原子操作, 具体操作一般用final修饰不能被本类修改

不能用 interface 接口来代替抽象类 无法写具体操作(算法)的流程

Singleton
确保某一个类 只有一个实例
实现方法
将一个静态的 该类的实例 声明为该类的
成员变量
将构造函数声明为private
声明一个获取该实例的静态方法getInstance()
这样静态方法操作静态实例 没有new一个该实例
的入口 就只有这一个实例了

Prototype 模式
角色
Prototype 原型
用于定义复制现有实例的方法
ConcretePrototype 具体的原型
用来实现复制现有实例的方法
Client 使用者(Manager)
负责管理 类的别名和实例
例如用HashTable来存储
复制的方法是Object类的clone方法

Abstract Factory
角色:
Abstract Product 抽象产品的API
Abstract Factory 定义具体工厂的一些基本方法
这里的工厂的作用就是生产出产品,所以方法
在这里应该很明白就是获得就产品实例的方法
Concrete Product 具体的产品继承自抽象产品
完成产品功能
Concrete Factory具体的工厂继承Abstract factory并完成其中的
方法
这里为了Link 和 tray 可以替换,并且存在递归添加的问题定义了一个父类接口,来实现
子类的通用

生成具体工厂时 用到方法 Class.forname().newInstances();
让生成的具体工厂可更改替换

Bridge 模式

1.功能层次结构和实现层次结构: 顾名思义,一个注重与功能的扩展,一个注重于功能的实现

功能层次结构是通过继承的方式来扩展现有功能,可以有纵向
(功能不冲突时)和横向(功能有冗余或者不匹配的时候)两种方式

实现层次结构是通过继承来实现父类的抽象方法,通常时横向的结构(只有一层)
此时的接口api可以替换成多种不同的实现

2.角色: Abstraction(抽象化): 使用Implementor 中的方法定义了基本的功能,该类中 保存了Implementor 的一个指针,在构造函数中由外部传入。这种在类中保存指针 具体实现由指针所指代的类来实现的模式叫做委托 RefineAbstraction(扩展的抽象化): 增加了新功能的抽象化 Implementor (实现者): 实现层次的最上层,用于定义其API ConcreteImplemetor(具体的实现者): 真正干活的类

3.Bridge类用于实现功能层次结构和实现层次结构的 分离,具体实现可以根据显示需要被替换,如不同操作系统 下的适配。 4.后续添加新功能或者维护的时候也应遵循层次结构和实现结构分离的原则

Strategy 模式 角色: Strategy API 用于定义实现策略所必需的接口api concreteStrategy 具体的策略 实现了StrategyAPI的具体策略,真正实现策略的类 Context 上下文 里面保存了Strategy具体实现的类,调用公共的接口实现功能

另:java中访问控制 的对象是类!是类!是类! 所以不要奇怪相同类的 不同实例可以互相访问private 参数这个现象了