大部分时候写的代码太乱了,找点逻辑看看。这个是从《人人都懂设计模式》里摘录的,加上我可能用到的理解。写给自己参考的。花了3天读了一下。
一种实现形式,从基类到特定的子类。最为常用,空心箭头,实线。
实现的强弱关系和泛化一样,不一样的是父类为接口,使用的是虚线而不是实线。
在visio里较复合,其中被聚合的部分离开整体后无法单独存在。因此关系之间更强。实心菱形,实线。电脑为调用者,组件为被调用者。
被聚合的类可以离开整体而单独存在。公司为调用者,员工为被调用者。
一种调用关系,从调用者指向被调用者,调用者操作被调用者的类。为下图上面。
一种调用关系,从调用者指向被调用者,调用者操作被调用者的方法。为下图下面。
1. 创建被观察者和观察者
2. 将观察者添加到被观测者列表
3. 对被观测者进行数据操作
4. 被观察者通过观察者的内部方法访问,对其进行通知
5. 通知过程中,观察者可能需要通过被观察者的内部方法访问,获得数据信息。
1.【用户】创建上下文环境实现类
2. 【上下文环境实现类】添加状态类到上下文环境类中的数组
3. 【用户】调用上下文环境类的行为
4. 【上下文环境实现类】根据当前的状态调用对应状态的行为
5. 【用户】改变上下文环境类的属性信息
6. 【上下文环境实现类】根据改变的信息遍历状态,获取状态的行为信息
1. 创建中介对象
2. 创建交互对象
3.交互对象中传入中介对象方法,添加交互对象到中介对象
4. 用户对象中传入中介对象方法,获取中介对象提供的服务,间接知道交互对象
【交互复杂度转换为了中介的复杂度导致的中介复杂,多个使用者等问题】
【组件1和组件2为出口,装饰器为栈调用形式,每个装饰器实现中存放了上一个装饰器实现,最深的一层为组件】
1. 【用户】创建组件1
2. 【用户】创建装饰器1,并将组件1传入装饰器1,得到装饰器1
3. 【用户】创建装饰器2,并将装饰器1传入装饰器2,得到装饰器2
4. 【用户】调用装饰器的函数功能,【函数功能】调用自身的【添加行为】方法,对存放的上一层【函数功能】进行调用。
5. 【最后一层】【函数功能】为组件,调用组件的函数功能,最后调用栈向上走,到最后一程装饰器的【函数功能】
6. 结束
【使得用户只能从该类中创建一个对象,继续创建则返回第一个创建的对象实例】
【匿名对象好像默认就是单例的啊,创建的地址都一个】
1. 重写__new__方法,当首次创建对象,则将实例保存,后续创建则使用第一次的实例,保存的位置为类的私有变量,__init__方法修改为首次创建,则进行初始化,否则不初始化。首次创建的flag存放在类的私有变量。
2. 自定义metaclass
3. 自定义装饰器实现。
def decoder_x(cls, *args, **kwargs):
instance = {}
def wrap_x(*args, **kwargs):
if cls not in instance:
instance[cls] = cls(*args, **kwargs)
return instance[cls]
return wrap_x
克隆出一样的,然后修改吧,deepcopy
1. 创建请求者和责任者们
2. 为请求者和责任者创建上层责任者
3. 【用户】发送请求,责任者1处理请求,然后判断是否调用上层责任者
4. 上层责任者依次处理请求。
【这里的客户端指代用户】
1. 【用户】创建真实主题类
2. 【用户】创建代理主题类,并将真实主题类传入
3. 【用户】对【代理主题类】发送请求,代理主题类经过前处理,访问真实主题类,后处理,完成请求过程。
【外观模式为复杂的子系统提供了一层抽象,当子系统无法真实维护,但又可用,创建对外的统一接口,方便使用】
【客户端和用户含义相同】
1.【用户】创建外观类
2.【外观类】挂载子系统类
3.【用户】操作外观类,【外观类】访问子系统,完成功能。
【迭代器模式,客户端一般通过next方法获取下一个元素等】
iter函数将可迭代数据类型转换为迭代器类型,可使用next方法。
1. 【用户】创建一些组成部分
2. 【用户】添加一些组件到各个组成部分
3. 【用户】将子组成部分添加到组成部分
4. 【用户】最大的组成部分执行操作,如显示特征,则逐个调用。
【组成部分的聚合关系,表示了组成部分会遍历其组件】
1. 【用户】创建构建者
2. 【用户】调用构建产品
3. 【构建者】创建并构建对应的产品
1. 【客户端】调用其他目标类的实现,正常
2. 【客户端】间接调用被适配对象,则通过适配器【直接】调用,适配器通过对被适配对象的修正,完成访问的方法。
【和什么外观模式,代理模式还有点像哈】
1. 【用户】创建上下文环境(它是需要策略的)
2. 【用户】创建策略如策略1,并将其装入上下文环境中
3. 【用户】执行上下文操作接口,【上下文环境】调用对应的策略执行动作。
sorted重写比较器就是这样简单的
我觉得工厂模式有点乱,可能是比较灵活的原因。其中UML绘制可能有点出入,但是大体思想是从工厂里,创建并返回对象。
可能二级工厂就够了,这个是三级的,不过用起来应该会很方便吧。
1. 【用户】创建工厂,如工厂1
2. 【用户】操作工厂,传入参数,工厂根据参数对产品创建,返回产品。
3. 【用户】操作产品的方法,完成任务。
我这里修改了客户端到调度者、命令为实线箭头。
【客户端和用户同义】
1. 【用户】创建调度者
2. 【用户】创建命令
3. 【用户】将命令放入调度者中
4. 【调度者】根据命令,选择执行命令,【命令】访问【接收和执行】,执行直接内容。
1. 【用户】创建发起人
2. 【用户】对发起人写入数据
3. 【用户】调用发起人创建备忘录
4. 【用户】创建备忘录管理器,将备忘录插入管理器
5. 【用户】从备忘录管理器中获取备忘录,调用发起人,传入备忘录,从而恢复数据
【客户端理解为用户,用户在访问工厂中的产品时,因资源限制,这些产品是公共享用的,且只生成一次(set判断)】
1. 【用户】创建轻量级工厂,传入参数获得指定轻量级
2. 【轻量级工厂】根据是否创建了对应的轻量级,来动态创建轻量级,并返回给用户
3. 【用户】操作轻量级,完成功能。
非共享轻量级可能和工厂模式或者构建模式像。
【客户端是用户】
1. 【用户】创建数据结构管理器,创建数据节点
2. 【用户】将数据节点插入数据结构管理器中
3. 【用户】创建访问者,将访问者传入数据结构管理器,执行动作。
4. 【数据结构管理器】执行客户端行为,调用数据节点的访问方法
5. 【数据节点】调用访问者的访问方法,完成访问操作。
我觉得就是抽象类和具体类的区别吧,一套公用的接口,然后大家都实现它。
说是和策略模式有点像,我想是这样的:桥接模式是用于对代码重构的思考,如果程序层次性太深或拓展性不够,是否可将下层的部分作为上层的一个组件形式,即聚合关系,桥接到上层。
【抽象类(形状)实现类(颜色)桥接,从而用户在创建形状的时候,尽管有各种形状和各种颜色,但是因为颜色成为一个形状的组件,因此只需关注形状类,而颜色类可以自由拓展】
【用于表达式的解析和执行上】
1. 【用户】将数据传入到抽象表达式中,根据表达式常用的思路,以栈的形式首先对表达式解析,然后存储到栈中。
2. 【抽象表达式】通过逐层调用,找到最内部的表达式,解析并将结果返回给上层表达式。
3. 以此类推,获得最终结果。