下面逐一简要介绍

适配器Adapter设计模式是一种结构型设计模式它允许接口不兼容的类之间进行合作。

适配器模式充当两个不兼容接口之间的桥梁使得它们可以一起工作而无需修改它们的源代码。

主要角色

实现目标接口并且持有一个被适配者的实例将客户端的请求转换为被适配者能够处理的形式。

被适配者Adaptee

拥有一组不兼容目标接口的方法适配器通过包装被适配者使其能够与目标接口协同工作。

客户端Client

EnglishSpeaker(ABC):abstractmethoddef

被适配者

FrenchToEnglishAdapter(EnglishSpeaker):def

__init__(self,

french_speaker):self.french_speaker

french_speakerdef

speak_english(self):french_phrase

self.french_speaker.parler_francais()#

这里可以进行一些转换操作这里简单地将法语短语翻译成英语english_translation

speak

communicate_in_english(english_speaker):print(english_speaker.speak_english())#

创建被适配者

FrenchToEnglishAdapter(french_speaker)#

客户端调用

communicate_in_english(adapter)1.2

通过适配器模式原本不兼容的类可以被一起使用避免了重写代码的需求从而提高了代码的复用性。

2灵活性和扩展性

可以通过编写新的适配器轻松地将现有类与新接口或新系统集成在一起增加系统的灵活性和扩展性。

3遵循开闭原则

适配器模式允许扩展系统而不改变现有的代码结构符合面向对象设计的开闭原则对扩展开放对修改关闭。

4解耦

适配器模式将客户端与被适配的类解耦使客户端不需要关心被适配类的接口细节只需要使用适配器提供的接口。

如果过度使用适配器模式可能会导致系统中出现大量的适配器类增加了代码的复杂性和维护难度。

2性能开销

由于适配器模式涉及对象的间接调用可能会导致一定的性能开销特别是在高性能要求的系统中。

适配器模式虽然解决了接口不兼容的问题但它可能会掩盖一些设计上的问题。

如果系统设计时能够提前规划好接口这样的适配可能本不需要。

引入适配器后系统的结构变得更加复杂可能会让代码的可读性下降特别是对于不熟悉这种模式的开发人员。

代理模式

Pattern是一种结构型设计模式。

在代理模式中代理对象充当了另一个对象的占位符以控制对该对象的访问。

代理对象和被代理对象实现了相同的接口因此它们可以互相替代。

客户端和代理对象之间的交互是无缝的因为它们的接口是一样的。

代理模式的主要功能是为其他对象提供一个代理以控制对对象的访问。

代理对象可以在调用被代理对象之前或之后执行一些操作例如身份验证缓存等。

主要角色

Proxy类实现抽象角色是真实角色的代理通过真实角色的业务逻辑方法来实现抽象方法并可以附加自己的操作

RealSubject实现抽象角色定义真实角色所要实现的业务逻辑供代理角色调用

2.1

Subject(metaclassABCMeta):abstractmethoddef

request)class

RealSubject()self.subject.Request()class

Client(object):def

3可以提高系统的灵活性因为代理对象可以在不影响真实对象的情况下扩展其功能。

2如果代理对象没有正确实现与真实对象相同的接口可能会导致客户端代码无法正常工作。

桥接模式

Pattern)将抽象部分与它的实现部分分离使它们都可以独立地变化。

它是一种对象结构型模式又称为柄体(Handle

and

通俗点讲就是在不同的地方之间搭一座桥让他们连接起来可以相互通讯和使用。

桥接模式中的桥接是单向的也就是只能是抽象部分的对象去使用实现部分的对象而不能反过来也就是个单向桥。

主要角色

抽象化(Abstraction)角色抽象化给出的定义并保存一个对实现化对象的引用。

修正抽象化(Refined

Abstraction)角色扩展抽象化角色改变和修正父类对抽象化的定义。

实现化(Implementor)角色这个角色给出实现化角色的接口但不给出具体的实现。

必须指出的是这个接口不一定和抽象化角色的接口定义相同实际上这两个接口可以非常不一样。

实现化角色应当只给出底层操作而抽象化角色应当只给出基于底层操作的更高一层的操作。

具体实现化(Concrete

Implementor)角色这个角色给出实现化角色接口的具体实现

什么场景下会用到桥接模式

https://www.cnblogs.com/baxianhua/p/11358707.html

设想如果要绘制矩形、圆形、椭圆、正方形我们至少需要4个形状类但是如果绘制的图形需要具有不同的颜色如红色、绿色、蓝色等

显然后一种更为合适

对于有两个变化维度即两个变化的原因的系统采用方案二来进行设计系统中类的个数更少且系统扩展更为方便。

设计方案二即是桥接模式的应用。

3.1

Implementor(ABC):abstractmethoddef

ConcreteImplementorA(Implementor):def

ConcreteImplementorB(Implementor):def

抽象类

RefineAbstraction(Abstraction):def

Operation(self):self.implementor.Operation()if

__name__

RefineAbstraction(b)aa.Operation()ab.Operation()3.2

2桥接模式有时类似于多继承方案但是多继承方案违背了类的单一职责原则即一个类只有一个变化的原因复用性比较差而且多继承结构中类的个数非常庞大桥接模式是比多继承方案更好的解决方法。

3桥接模式提高了系统的可扩充性在两个变化维度中任意扩展一个维度都不需要修改原有系统。

1桥接模式的引入会增加系统的理解与设计难度由于聚合关联关系建立在抽象层要求开发者针对抽象进行设计与编程。

2桥接模式要求正确识别出系统中两个独立变化的维度因此其使用范围具有一定的局限性。

享元模式

Pattern是一种结构型设计模式用于减少创建对象的数量以提高应用程序的性能。

享元模式通过共享尽可能多的数据来减少内存使用。

主要角色

抽象享元角色(FlyWeight)享元对象抽象基类或者接口,同时定义出对象的外部状态和内部状态的接口或实现;

具体享元角色(ConcreteFlyWeight)实现抽象享元类中的方法是需要共享的对象类

享元工厂(FlyWeightFactory)维护一个享元对象的池内部使用一个

Map

Flyweight(metaclassABCMeta):abstractmethoddef

class

ConcreteFlyweight(Flyweight):def

__init__(self,

factory.getFlyweight(cappuccino)c1_capp.operation()c2_mocha

factory.getFlyweight(mocha)c2_mocha.operation()c3_capp

factory.getFlyweight(cappuccino)c3_capp.operation()print(Num

Flyweight

Pattern外部与一个子系统的通信必须通过一个统一的外观对象进行为子系统中的一组接口提供一个一致的界面外观模式定义了一个高层接口这个接口使得这一子系统更加容易使用。

外观模式又称为门面模式它是一种对象结构型模式。

外观模式的核心在于将复杂的内部实现包装起来只向外界提供简单的调用接口。

类似现实世界中的电脑开机按钮可以说就是一个简单的调用接口帮用户屏蔽了复杂的内部电路。

5.1

humidifier):self.air_conditioner

air_conditionerself.water_heater

humidifierdef

arrive_home(self):print(Arriving

home...)self.air_conditioner.on()self.water_heater.on()self.curtains.open()self.humidifier.on()def

home...)self.air_conditioner.off()self.water_heater.off()self.curtains.close()self.humidifier.off()if

__name__

SmartHomeFacade(air_conditioner,

water_heater,

humidifier)smart_home.arrive_home()smart_home.leave_home()5.2

2客户端屏蔽了子系统组件减少了客户端所需处理的对象数目并使得子系统使用起来更加容易。

3这其实也是Python一直提倡的封装思想隐藏一些丑陋的系统提供API去调用不用管内部如何实现只需调用API即可实现相关功能。

1不能很好地限制客户使用子系统类

2在不引入抽象外观类的情况下增加新的子系统可能需要修改外观类或客户端的源代码违背了“开闭原则”。

组合模式

Pattern是一种结构型设计模式它允许你将对象组合成树形结构来表示“部分-整体”的层次结构。

组合模式使得客户端可以统一地处理单个对象和对象组合。

组合模式的适用场景表示部分-整体层次结构当需要表示对象的部分-整体层次结构时可以使用组合模式。

统一处理单个对象和组合对象当需要统一处理单个对象和组合对象时可以使用组合模式。

构建递归结构当需要构建递归结构如树形结构时可以使用组合模式。

主要角色

组件Component定义对象的接口并实现一些默认行为。

声明一个接口用于访问和管理Leaf和Composite中的子组件。

组合Composite定义有子部件的那些部件的行为存储子部件。

并在组件接口中实现与子部件有关的操作如添加、删除等

6.1

graphic):self.children.append(graphic)def

remove(self,

graphic):self.children.remove(graphic)def

get_child(self,

组合图形composite1.add(circle1)composite1.add(circle2)composite2.add(square1)composite2.add(composite1)#

__name__

1统一处理单个对象和组合对象组合模式使得客户端可以统一地处理单个对象和对象组合提高了代码的灵活性和可扩展性。

2简化客户端代码客户端代码可以一致地使用组件接口而不需要关心处理的是单个对象还是组合对象。

3符合开闭原则可以通过增加新的叶子和组合类来扩展系统而不需要修改现有代码。

1增加复杂性组合模式会增加系统中类和对象的数量可能会使系统变得复杂。

2难以限制组合层次有时需要对组合层次进行限制但组合模式本身没有提供这样的机制。

装饰器模式

Pattern是一种结构型设计模式它允许将行为动态添加到一个对象中而不必改变该对象的类。

这种模式利用了组合的方式以在运行时动态地添加功能同时避免了静态类继承的缺点。

装饰器模式的基本思想是将一个对象“包装”在另一个对象中从而实现增强原有对象的功能而不改变原有对象的结构。

这种方式可以让我们通过添加新的装饰器来动态地改变对象的行为而无需对其进行修改。

装饰器模式的实现通常涉及创建一个抽象的装饰器类和一个具体的装饰器类这个具体的装饰器类可以添加额外的行为或修改对象的行为。

同时还需要创建一个具体的组件类它是被装饰的对象。

最终装饰器模式将组件类和装饰器类组合起来以实现动态添加功能的目的。

装饰器模式常常应用于需要动态添加功能或修改对象行为的场景例如在不改变现有代码的情况下为一个类添加新的功能或在运行时添加日志、缓存等功能。

7.1

say_hello():print(Hello!)say_hello()7.2

1增强对象功能装饰器模式可以增强一个对象的功能而不需要修改原始对象的代码。

通过添加不同的装饰器可以在运行时为对象增加不同的功能从而满足不同的需求。

2可扩展性装饰器模式非常灵活允许在运行时动态地添加或删除功能因此非常适合应对需求的变化。

3组合性装饰器模式允许将多个装饰器组合在一起使用从而实现更复杂的功能。

4单一职责原则装饰器模式遵循单一职责原则每个装饰器只关注一个特定的功能使得代码更加清晰简洁。

5开闭原则装饰器模式遵循开闭原则可以在不修改原始对象的情况下扩展其功能从而保证了系统的可维护性和可扩展性。

1增加了代码复杂性使用装饰器模式会增加代码的复杂度因为需要创建多个类来实现装饰器。

2可能会导致性能问题由于装饰器是通过递归来实现的可能会对性能产生一定的影响尤其是在多层嵌套的情况下。

可能会出现装饰器的堆叠问题当多个装饰器同时应用于同一对象时可能会出现装饰器的堆叠问题导致代码变得难以理解和维护。

3可能会破坏对象的封装性使用装饰器模式会暴露对象的内部细节可能会破坏对象的封装性导致代码变得不安全和不稳定。