sdsc1314的博客

在特定领域中，某些变化虽然频繁，但可以抽象为某种规则。这时候，结合特定领域，将问题抽象为语法规则，从而给出在该领域下的一般性解决方案。①只有满足“业务规则频繁变化，且类似的结构不断重复出现，并且容易抽象为语法规则问题”才适合Interpreter模式。②Interpreter模式比较适合简单的文法表示，对于复杂的文法表示，Interpreter模式会产生比较大的类层次结构，需要求助于语法分析生成器这样的标准工具。...

在组件的构建过程中，组件行为的变化经常导致组件本身剧烈的变化。“行为变化”模式将组件的行为和组件本身进行解耦，从而支持组件行为的变化，实现两者之间的松耦合。命令模式（Command）①Command模式的根本目的在于将“行为请求者”和“行为实现者”解耦。②Command模式与C++中的函数对象有些类似。但两者定义行为接口的规范有所区别：Command以面向对象中的“接口-实现”来定义行为接口规范，更严格，但有性能损失；C++函数对象以函数签名来定义行为接口规范，更灵活，性能更高。访问器（Visito

常常有一些组件在内部具有特定的数据结构，如果让客户程序依赖这些特定的数据结构，将极大地破坏组件的复用。这时候，将这些特定的数据结构封装在内部，在外部提供统一的接口，来实现与特定数据结构无关的访问，是一种行之有效的解决方案。组合模式（Composite）①Composite模式采用树形结构来实现普遍存在的对象容器，从而将“一对多”的关系转化为“一对一”的关系，使得客户代码可以一致地（复用）处理对象和对象容器，无需关心处理的是单个对象还是组合的对象容器。②将“客户代码与复杂对象容器结构”解耦是Compos

在某些构建过程中，某些对象的状态经常面临变化，如何对这些变化进行有效的管理？同时又维持高层模块的稳定？状态变化模块为这一问题提供了一种解决方案。状态模式（State）①State模式将所有与一个特定状态相关的行为都放入一个State的子类对象中，在对象状态切换时，切换相应的对象；但同时维持State的接口，这样实现了具体操作与状态转换之间的解耦。②如果State对象没有实例变量，那么各个上下文可以共享同一个State对象，从而节省对象开销。备忘录（Memento）①Memento模式的核心是信息隐

在组建的构建过程中，某些接口之间直接的依赖常常带来许多问题、甚至根本无法实现。采用添加一层间接（稳定接口)，来隔离本来互相紧密关联的接口是一种常见的解决方案。门面模式（Facade）①从客户的角度来看，Facade模式简化了整个组件系统的接口，对于组件内部与外部客户程序来说，达到了一种“解耦”的效果–内部子系统的任何变化不会影响到Facade接口的变化②Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。③Facade设计模式并非一个集装箱，可以任意地放进任何多个对象。Facad

面向对象很好的解决了“抽象”问题，但是不可避免地要付出一定的代价。对于通常情况来讲，面向对象的成本大多可以忽略不计。但在某些情况下，面向对象的成本必须谨慎处理。单例模式（Singleton)Singleton模式一般不要支持拷贝构造函数和Clone接口，因为这有可能导致多个对象实例，与Singleton模式初衷违背。享元模式(Flyweight)...

通过“对象创建”模式绕开new，来避免对象创建(new)过程中所导致的紧耦合，从而支持对象创建的稳定。工厂方法(Factory Method)①Factory Method模式用于隔离类对象的使用者和具体类型之间的耦合关系。面对一个经常变化的具体类型，紧耦合关系会导致软件的软弱。②Factory Method模式通过面向对象的手法，将所要创建的具体对象工作延迟到子类，从而实现一种扩展（而非更改）的策略，较好地解决了这种紧耦合关系。③Factory Method模式解决单个对象的需求变化，缺点在于要求

1.装饰模式（Decorator)①通过采用组合而非继承的方法，Decorator模式实现了在运行时动态扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了使用继承带来的灵活性差和多子类衍生问题②Decorator类在接口上表现为is-a Component的继承关系，即Decorator类继承了Component类所具有的接口。但在实现上又表示为has-a Component的组合关系，即Decorator类又使用另外一个Component类2.桥模式（Bridge）...

1.模板方法（Template method）2.策略模式（Strategy)①Strategy及其子类为组件提供了一系列可重用的算法，从而可以使得类型在运行时方便地根据需要在各个算法之间切换②Strategy提供了用条件判断语句以外的另一种选择，消除条件判断语句，就是在解耦合。含有许多条件判断语句的代码通常都需要Strategy模式③如果Strategy对象没有实例变量，那么各个上下文可以共享同一个Strategy对象，从而节省对象开销...

1.依赖倒置原则（DIP）①高层模块（稳定)不应该依赖于低层模块（变化），二者都应该依赖于抽象（稳定）②抽象（稳定）不应该依赖于实现细节（变化），实现细节应该依赖于抽象（稳定）2.开放封闭原则（OCP）①对扩展开放，对更改封闭。②类模块应该是可扩展的，但是不可修改3.单一职责原则（SRP）①一个类应该仅有一个引起它变化的原因②变化的方向隐含着类的责任4.liskov替换原则（LSP）①子类必须能够替换它们的基类②继承表达类型抽象5.接口隔离原则（ISP)①不应该强迫客户程序依赖它们