摘要:内容: 定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。 模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。 角色: 抽象类(AbstractClass):定义抽象的原子操作(钩子操作); 实现一个模板方法作为算法的骨架。 具体类(ConcreteClass):实现原子操
阅读全文
摘要:内容: 定义一系列的算法,把它们一个个封装起来,并且使它们可互相转换。 本模式可独立于使用它的客户而变化。 角色: 抽象策略(Strategy) 具体策略(ConcreteStrategy) 上下文(Context) 优点: 定义一系列可重用的算法和行为 消除了一些条件语句 可以提供相同行为的不同实
阅读全文
摘要:内容: 定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。 观察者模式又称“发布-订阅”模式 角色: 抽象主题(Subject) 具体主题(ConcreteSubject) ——发布者 抽象观察者(Observer) 具体观察者(Concret
阅读全文
摘要:内容: 使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。 将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。 角色: 抽象处理者(Handler) 具体处理者(ConcreteHandler) 客户端(Client) 适用场景: 有多个对象可以处理一个请
阅读全文
摘要:内容: 为其他对象提供一种代理以控制对这个对象的访问 应用场景: 远程代理:为远程对象提供代理 虚代理:根据需要创建很大的对象 保护代理:控制对原始对象的访问,用于对象有不同访问权限时 角色: 抽象实体(Subject) 实体(RealSubject) 代理(Proxy) 优点: 远程代理:可以隐藏
阅读全文
摘要:内容:为子系统中的一组接口提供一个一致的界面,外观模式定义了一个高层接口, 这个接口使得这一子系统更加容易使用 角色: 外观(facade) 子系统类(subsystem classes) 优点: 减少系统相互依赖 提高了灵活性 提高了安全性 查看代码 class CPU: def run(self
阅读全文
摘要:内容: 将对象组合成树形结构以表示“部分-整体”的层次结构。 组合模式使得用户对单个对象和组合对象的使用具有一致性 角色: 抽象组件(Component) 叶子组件(Leaf) 复合组件(Composite) 客户端(Client) 适用场景: 表示对象的”部分-整体“层次结构(特别是结构是递归的)
阅读全文
摘要:内容: 将一个事物的两个维度分离,使其都可以独立地变化 角色: 抽象(Abstraction) 细化抽象(RefinedAbstraction) 实现者(Implementor) 具体实现者(ConcreteImplementor) 应用场景: 当事物有两个维度上的表现,两个维度都有可能扩展时 优点
阅读全文
摘要:内容:将一个类的接口转换成客户希望的另一个接口。 适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作了。 两种实现方式: 类适配器:使用多继承 对象适配器:使用组合 角色: 目标接口(Target) 待适配的类(Adaptee) 适配器(Adapter) 适用场景: 想使用一个已经存
阅读全文
摘要:内容:保证一个类只有一个实例,并提供一个访问它的全局访问点 角色: 单例(Singleton) 优点: 对唯一实例的受控访问 单例相当于全局变量,但防止了命名空间被污染 查看代码 class Singleton: """通过重写new方法,确保每次实例化只有一个实例对象 nwe方法在init之前调用
阅读全文
摘要:内容:将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。 角色: 抽象建造者(Builder) 具体建造者(Concrete Builder) 指挥者(Director) 产品(Product) 建造者模式与抽象工厂模式相似,也用来创建复杂对象,主要区别是建造者模式着重一步步
阅读全文
摘要:内容:定义一个工厂类接口,让工厂子类来创建一系列相关或互相依赖的对象。 列: 生产一部手机,需要手机壳、CPU、操作系统三类对象进行组装,其中每类对象都有不同的种类。 对每个具体工厂,分别生产一部手机所需要的三个对象。 相比工厂方法模式,抽象工厂模式中的每个具体工厂都生产一套产品。 角色: 抽象工厂
阅读全文
摘要:内容:定义一个用于创建对象的接口(工厂接口),让子类决定实列化哪个一个产品类。 角色: 抽象工厂角色(Creator) 具体工厂角色(Concrete Creator) 抽象产品角色(Product) 具体产品角色(Concrete Product) 优点: 每个具体产品都对应一个具体工厂类,不需要
阅读全文
摘要:1.开放封闭原则:一个软件实体如类,模块和函数应该对扩展开放,对修改关闭。 即软件实体应尽量在不修改原有代码的情况下进行扩展。 2.里氏替换原则:所有引用父类的地方必须能透明地使用其子类的对象。 3.依赖倒置原则:高层模块不应该依赖低层模块,二者都应该依赖其抽象; 抽象不应该依赖细节,细节依赖抽象。
阅读全文