SAP领域技术博客

1. 定义观察者模式也称“发布-订阅模式（Pubish/Subscribe）”, “模型-视图模式（Model/View）”, “源-监听器模式（Source/Linster）”或者“从属者模式（Dependents）”, 它是一种行为型模式。此种模式定义了一种“一对多”的依赖关系，多个观察者可同时监听某一个主题对象，当主题对象状态改变时，其相关的依赖对象皆得到通知，并自动更新自己。2. 解读类比：这个模式的例子真的太多了。例如，订阅报纸（杂志），这其实是形成了一种订阅者和出版商之间的依赖关系，

1.目的定义一个操作中算法的骨架，将一些步骤延迟到子类中。模板方法模式使得子类可以在不改变算法结构的前提下，重写算法的某些步骤。2.解读类比：我们的日常生活中，可以遇到很多的模板。例如，编写简历时，我们会使用一些简历模板；填写表格时，会有一个填表的参照模板；编写文章时，根据叙事方式的不同，也可参照相应的写作模板。可以说，“模板”其实充斥在我们日常生活中。想一想，模板的好处是什么？模板可以为使用者提供一个参照对象，并将某些方面固化下来，形成“套路”。这种方式简化了操作步骤，并提升了效率。在面向对

1. 概述“结构型模式”是GoF设计模式中的第二大类，包括了适配器模式、装饰模式、外观模式、代理模式、桥接模式、组合模式以及享元模式7种。其中，适配器模式、装饰模式、外观模式和代理模式，都是通过wrapper结构的引入，为类的访问提供间接性，从而提升设计的灵活性，它们4种同属“包装模式家族”。2. 目的在盖房子前，我们需要明确房屋的用途，然后设计合理的房屋结构，最后通过钢筋、水泥、管道、电路等等元素的合理使用，最终完工一项工程。在面向对象的程序世界中，“结构化模式”描述了类与类之间的结构关系，通过

1.目的运用共享技术，支持大量细粒度的对象。享元模式又称“轻量级模式”，也就是Flyweight的直译 ????2.解读类比：“享元”是个很时尚的概念，它其实体现的就是“共享模式”的思想。现在出现的共享经济模式，例如共享单车，共享汽车，共享充电宝等等，其实都是“享元”的思想。它的核心点是什么呢？其实，就是通过共享的方式，提高资源、物品的使用效率。以共享单车为例，如果没有共享单车，想骑车出行的话，我们不得不自己购买一辆自行车。但如若是使用共享单车，骑车的事情就变得很“轻量级”，需要时便扫码使用，不

1.目的将对象组合成树形结构，以表示“部分-整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有"一致性"。2.解读类比：在现实生活中，我们会遇到很多的树状结构。例如，公司的组织架构（总公司-分公司），文件系统的层级结构，目录的层级结构，以及页面控件的层级关系等等。组合模式，就是一种利用面向对象的方式，来处理“部分-整体”关系的设计模式。解析：组合模式中包含两种类型的对象，复杂对象（e.g. 文件夹）和原子对象（文件）。复杂对象中可进一步包含子元素，而原子对象是最小单元，无

1. 目的将抽象部分与它的实现部分分离，使得它们都可以独立地变化。桥接模式（Bridge）也称：柄体模式(Handle and Body)或接口模式(Interface)。2. 解读类比：先举一个生活中的例子，比如“蜡笔”。如果我们需要12种颜色，那么我们准备12支对应颜色的蜡笔即可。但如果我们需要大、中、小号的三种蜡笔，并且都要有12种颜色，我们可能不得不买3盒不同型号的蜡笔，并且每盒都包含12种颜色。有没有其它的思路呢？如果是毛笔呢？可不可以准备大、中、小三只毛笔，然后配上12种颜色盒呢？

1. 意义“创建型模式”是GoF设计模式的第一大类，主要包括了工厂模式、单例模式、原型模式和建造者模式4种。本篇，我们对创建型模式进行一个小结。存在的意义：创建型模式隐藏了了类的实例化过程，客户端使用目标类时，不需要NEW，而是通过创建模式提供的实例化方法来获取对象这样，创建型模式在创建什么，谁创建它，它是怎么被创建的，以及何时创建这些方面提供了很大灵活性创建型模式可以独立使用，当然，也是可以结合使用的。例如工厂方法模式和单例模式结合，单例存放在工厂类中，工厂方法返回单例的实例对象。典型代

1.目的将一个复杂对象的构建过程与它的表示分离，使得同样的构建过程，可以创建不同的表示。2.解读类比：建造者模式类似于模拟现实世界中供应商和组装厂的关系。什么意思呢？举个栗子 ????手机的生产过程其实就是一个很好的例子。一个手机“对象”是很复杂的，但如果不同的角色如果分工合作，扬长避短，那么就会极大降低手机生产的复杂度。也即，品牌厂商仅负责手机的设计工作，而手机的零件可以从不同的供应商采购，最终由代工厂完成手机组装。手机厂商、零件供应商和代工厂就是我们“建造者模式”的主角。解析：这个模

1. 定义保证一个类仅有一个实例，并提供一个访问它的全局访问点。2. 解读类比：单例模式的主要目的是控制类的实例数量，确保有且仅有一个实例，有点像“类的计划生育”，O(∩_∩)O哈哈~解析：使用单例模式，要加深一些基本概念的理解，也即类的构造方法、可视区域、静态方法、静态成员变量几个概念通过对于构造方法的控制，可以控制类的实例化范围；静态成员变量的使用，可以控制实例的数量；静态方法，则提供了类实例化的唯一访问点单例模式可与工厂模式结合使用，将工厂类定义为生产类的Friends, 工厂类

1. 目的工厂模式家族包括：简单工厂方法模式（Simple Factory Method Pattern），简单工厂模式（Simple Factory Method Pattern），工厂方法模式（Factory Method Pattern），抽象工厂模式（Abstract Factory Pattern）。工厂模式的核心，其实主要为实现以下几个目的：控制类的实例化过程隔离生产类与调用方，解耦合提升设计的灵活性2. 使用场景辨析在下面这个图表中，我们可以看到4中模式的异同，通过超链接可以

1. 定义提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。工厂类中提供了多个创建方法，分别负责相关类的实例化。一个工厂类，对应的多个相关的生产类。2. 解读类比：抽象工厂模式，是工厂方法模式的一个扩展。还记得工厂方法模式的那个类比么 ????工厂方法模式中的工厂，小而美，每个工厂仅生产一种产品。这种方式，带来的一个问题就是，工厂类的数量会和生产类的数量一样多。在现实生活中，其实仅生产一种产品的工厂是少之又少的，大多数工厂其实都是生产某一品类的产品，不同的产品之间是相关的。

1. 定义定义一个用于创建对象的接口，让工厂类决定实例化哪一个生产类。工厂方法使一个生产类的实例化，延迟到对应的工厂子类中。每一个生产类，都有一个与之对应的工厂类。2. 解读类比：工厂方法模式中的工厂较简单工厂模式中的工厂有明显的区别。简单工厂模式中的工厂类，像一个综合工厂，大而全，可以生产各种各样的产品；而工厂方法模式中的工厂，小而美，每个工厂仅生产一种产品。解析：工厂方法模式是简单工厂模式的改进版，当生产类增加时，无需修改已有的工厂类，而是新增工厂类，符合开放-封闭原则。但仔细观

1. 定义通过拷贝原型本身，创建新的对象。原型模式属于创建型模式的一种。2. 解读类比：这个设计模式在现实生活中也能找到对应的例子。我们经常使用的“复制粘贴”快捷键，其实通过“拷贝”的方式进行的。Ctrl + C 来选中并复制对象，Ctrl + V 粘贴新生成的对象。解析：原型模式，其实就是通过复制一个实例对象，来生成另外一个可定制对象的过程。也即，通过复制，来实现类的实例化。当对象的实例化过程非常复杂时，可以考虑使用原型模式，通过克隆的方式，动态地获得对象运行时的状态，并在此基础上

1. 目的代理模式（Proxy Pattern），装饰模式(Decorator Pattern ) ，适配器模式(Adapter Pattern) 以及外观模式(Facade Pattern)都属于包装模式(Wrapper Pattern)的一种。熟悉这几种设计模式的同学可以回忆一下，以上这4种包装模式家族的成员，在功能上和使用场景上有何异同？其实，这4中模式的精神内核是相同的，也即，通过Wrapper增加对于目标对象访问的间接性。2. 使用场景辨析在下面这个图表中，我们可以看到4中模式的异同，

1. 定义策略模式，定义了算法（规则）家族，分别封装起来，让它们之间可以相互替换。此模式让算法（规则）的变化，不会影响到使用算法的客户。2. 解读优点：开放封闭原则的典型应用（面向接口编程，而非面向实现编程）抽象需求中功能的部分为接口，也即封装变化 （向修改封闭）在具体的算法类中实现接口（向扩展开放）是最常用的一种设计模式，经常与简单工厂模式结合使用弊端：客户端需要了解不同算法间的区别复杂场景中，可能出现额外的通信开销。接口定义的参数会是一个全集（覆盖所有场景），具体的实现类中，

1. 定义用一个单独的工厂类(factory class)，来控制实例化过程。2. 解读类的功能与类的实例化的过程分离 隐藏生产类（production class）的功能信息 工厂类提升实例化过程的灵活性（不同的场景，返回不同的实例；动态返回实例）3. 举例3.1 Factory根据类型返回实例REPORT zsimple_factory_pattern.********************************************************..

1. 定义用一个静态的工厂方法 (Factory Method /CREATIONMethod)实现类的实例化过程。工厂方法是类实例化的唯一途径。2. 解读隐藏了类实例化过程所需要知道的背景信息 工厂方法可以更具有描述性 使用类的过程，更接近于“开箱即用”（直接通过工厂方法拿到实例），而非去学习类的实例化条件（constructor）3. 举例*&-------------------------------------------------------------..

1. 定义LoD也称最少知识原则。如果两个类不必直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法，可以通过第三者转发这个调用。2. 解读在类的结构设计上，每一个类都应当尽量降低成员的访问自由度，仅适用直接对象，避免多层的间接访问。例如，当想获取max speed时，可以使用本方法中已有的对象mo_car直接获取mo_my_car->get_max_speed( )而非，mo_car->get_tacho( )->

1. 定义代码设计应该依赖于抽象，不应该依赖于实现细节。换句话说，抽象不应该依赖于细节，细节应该依赖于抽象。说白了，就是要针对接口编程，而非对实现编程。2. 解读依赖倒置原则其实是面向对象设计的标志，用那种语言实现并不重要，如果编写程序时，考虑的都是如何针对抽象编程，而非是针对细节编程，即程序中所有的依赖关系都终止于抽象类或接口，那就是面向对象的设计，反之就是过程化的设计。 为啥叫“依赖倒置”？其实这个名字来源于对于调用关系，调用方（consumer）不再直接依赖于服务的提供方（servi

1.定义一个类对另一个类的依赖，应该建立在最小接口上。客户端不应该依赖于它不需要的接口。2.解读其出发点在于“设计一个短小的接口或类”，避免大接口。小接口的设计，更容易实现高内聚、低耦合。 接口隔离，一定程度上也体现了“单一职责原则”，一个接口应当仅代表一个角色。但也有区别，一个类可能有若干方法，或实现了多个接口，但它们的目的是完成同一职责。 此原则更倾向于从调用方的角度出发，保证调用方可以克制地消费服务，防止过度消费 - 也即拥有无关的服务。也避免强迫调用方，依赖其并不需要的方法。 接口

1.定义子类型必须能够替换掉他们的父类型。2.解读子类可以扩展父类的功能，但不能改变父类原有的功能。也即：a) 子类可以实现父类的抽象方法，但不能覆盖/重写父类的的非抽象方法b) 子类可以增加自己的特有方法遵循上述原则的原因在于，继承是有入侵性的，所有的子类都会拥有父类的（非private）属性的方法。这使得父类与子类之间存在着“强耦合”，父类属性和方法的变化，会直接影响子类。保证父类的方法不被“覆盖/重写”，保证了继承链上行为的一致性，也使得父类的代码是...

1. 定义软件实体（类，函数，模块等）应该是可以扩展，但是不可修改。2. 解读开放-封闭原则（OCP）的两个特征：对于扩展时开放的(Open for extension)，对于更改是封闭的（Closed for modification）。 面对新需要的理想状态：对程序的改动是通过增加新代码进行的（例如，增加新的类，新的方法等），而不是更改现有的代码（例如，在原有逻辑中，增加 IF 的条件分支等）。 开放-封闭原则是面向对象程序设计的核心所在。遵循这个原则，是实现代码可维护、可扩展、可复用

1. 定义就一个类而言，应该仅有一个引起它变化的原因。2. 解读如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或是抑制这个类完成其他职责的能力。这种耦合会导致设计的脆弱性，当发生变化时，设计会遭受到意想不到的破坏。软件设计真正要做的许多内容，就是发现职责，并把这些职责相互分离。如果你能够想到多余一个动机去改变一个类，那么这个类就具有了多于一个的职责。换句话说，如果你无法在不使用任何连接词的情况下（例如“和”，“或”，“同时”等），描述一个类，那么这个类很大程度上

1. 目的增强程序的扩展性。2. 使用场景提取通用的逻辑，并预留出口，增加程序设计灵活性和可定制性，类似于SAP标准的BAdI。3. 类图4. 代码实现在下例中，通用的逻辑提取到lcl_salary_calculator中，并预留了lif_calculator接口。在不同场景下使用lcl_salary_calculator时，可以通过接口lif_calculator来实现定制化的逻辑。REPORT ztest_callback_pattern.**********************

1. 目的为子系统的一组接口提供一个一致、精简的访问界面。外观模式定义了一个高层接口，这个接口使得这一子系统（或一组相关的功能）更加容易使用。2. 使用场景外观模式完美体现了依赖倒置原则和迪米特法则的思想，是最常用的模式之一。首先，在设计阶段，应当有意思地将不同的功能层分离。例如经典的三层架构模型。层与层之间建立Facade。其次，在开发阶段，使用Facade来提供一个简单的接口，可以减少类之间的耦合。第三，在运维阶段，可以使用Facade来隔离高复杂度的遗留代码，让新对象与Facade交互，

1. 目的为其他对象提供一种代理，以控制对这个对象的访问。2. 使用场景代理模式气死就是在访问对象时引入一定程度的间接性，因为这种间接性，可以附加多种用途。例如：远程代理：也即为一个对象在不同地址空间提供局部代表。这样可以隐藏一个对象存在于不同地址空间的事实。虚拟代理：根据需要创建开销很大的对象。可以通过虚拟代理来存放实例化需要很长时间的真实对象。安全代理： 用来控制真实对象的访问权限。智能索引：在调用真实对象时，代理处理一些额外的工作。3. 类图4. 代码实现*

1. 目的动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式比生成子类更灵活。2. 使用场景把类中装饰的功能从类中搬出，这样可以简化原有的类。有效区分类的核心功能和装饰功能。使用时，应注意装饰类的调用顺序。当然，最理想的情况下，各个装饰类之间应当是相互独立的。3. 类图4. 代码实现*&---------------------------------------------------------------------**& Report zdecorat

1. 目的将一个类的接口转换成客户希望的另外一个接口。利用适配器Adapter，使得原本由于接口不兼容而不能一起工作的类可以一起工作。2. 使用场景适配器模式主要是希望复用一些现存的类，但接口又与复用环境要求不一致的情况。使用适配器模式，是一种开发上妥协的结果，也即服务调用方和提供方都不是很容易修改的时候，使用适配器作为一个中间的转化。在软件开发阶段，还是应当尽量保证接口的一致性，避免使用适配器；运维阶段，可能出现新需求，但需要复用现存的接口，此时可以妥协使用适配器模式。当然也有特殊情况，例如