ABAP OOP 面向对象设计原则 SAP

Abap oo学习理解

六大设计原则

---

---

前言

在敏捷开发中有十一种原则，但广受认同的为六种

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、单一责任原则（SRP）

单一责任原则srp（一个类只负责一个功能领域的职责）。

当业务场景中的某个功能领域business A相关的逻辑需要修改或者扩充时，我们需要修改相关的类class A。但是如果 功能B发生了变化,需要去修改class A，这就不符合单一原则。那为什么要这样呢，道理也很简单，如果相互影响就会大幅度降低可维护性。（如果继续有高耦合的特性，跟多个屏幕中主屏幕的PBO一样，余下的所有子屏幕都会过一遍中主屏幕PBO的代码，现实中也有这种例子瑞士有一把155种多功能的军刀。）

举个abap的例子:
class A 有三个方法

1. 获取工厂现有采购订单数据
2. 按多种情况生成分析图形
3. 输出到屏幕或者打印。

那现在class A 承担了过多职责，原因如下 : 获取采购订单数据是一个很通用的业务功能，而生成图形则是要根据多种情况来定。

那现在把A 拆分成 B 和C 。
类B :
方法1.根据传入的数据进行生成图形方法
2. 输出图形
类C ，获取采购订单数据（现在C不关心数据的用处。）

那现在单一责任原则是为了保证职责单一，功能明确的基础类，复杂的类应该是这些功能明确的类进行组合（即一个类是另外一个类的属性），或者配合接口使用。最主要的目的还是保证一个类有且只有一个职责，类中可以有多个方法，这些方法都是服务于同一个职责，其设计目标就是我们说的高内聚。

二、 开放封闭原则（OCP）

1.概念

开发封闭原则（OCP）功能业务发生变化时，尽可能添加新代码，而不是修改原来代码。当初Meyer提出这个原则，解决这个问题是采用依赖于面向对象继承（特别是从实际父类进行的实现继承）的方法，而不是直接修改原来程序。后面发生了改变，随着抽象类和接口等方式大量应用，开始提倡采用。而不是通过原来继承的方法来解决问题。为什么要这样呢，对于软件或者程序来说，在经历生命周期，需求业务会发生改变，修改时要保证稳定性以及可维护性。具体实现方式，通过深思熟虑定义一个相对稳定的抽象层，将业务行为下沉到具体的实现层。不管是业务有修改或拓展无须对抽象层进行修改。

2.举例

（示例如下）：

一个公司有多种物料类型，需要打印不同的检验说明单据。 那常规做法就是，利用判断只执行一次的if elseif，对多种物料类型进行逐个判断。
当然这种功能还只能存在一个程序里面，想进行迁移合并这些代码都要原封不动的搬过去，且每次新增都需要为这个程序添加一个打印方法修改主程序，并且对之前的程序做一次回退测试以此来保证不会受影响（特别是某些物料必须夹着特别的需求一个程序往往由几个程序员修改过，这样日积月累代码冗余，设计者一旦离职就是对该程序的毁灭打击，造成业务设计场景丢失，后续修改只能凭借经验进行改造）。

那我们该原则的设计要力求做到，源代码不修改，只新增或者基于规则进行修改源代码，保证工作量和代码出错减少 ，可维护性提高，这就是OSP。那采用这个原则进行重构，采用一个（改进的简单工厂模式，基于配置表），举例不会太难，实际情况可能不需要，但是理解了对于自己设计有帮助，十分值得。

首先 业务抽象分为三层:

1. 物料对象生成工厂类，用于创建物料类的对象实例
2. 抽象的物料类，由物料对象生成工厂类直接调用
3. 代表具体的物料类型，可以不断的从抽象类中继承和添加新的子类
   

第二层抽象类隔离开了操作类和具体的物料类 让主程序可以不必修改，就可以添加新的业务场景。

第一步创建抽象物料类，Zcl_Material，将多样的具体业务抽象成一种模式，类定义为抽象（Abstract）.
创建一个属性Mv_material 可见度为protected受保护的，type mara-matnr,
创建一个方法print_insp_desc , 可见为公共，不用参数也不用具体逻辑，这个方法表明了物料类拥有打印检验的能力，具体实现由子类各自实现。

第二步，创建第三层的抽象子类，分别为
成品物料fin 类
原料物料raw 类

这是最底层的，代表了具体实现代码，有新增也是在这一层继续创建类。 创建的时候继承自抽象物料类，子类自动继承属性，
然后我们重写继承来的方法desc（此方法是具体操作代码）。

第三步，创建配置表Zin_desc_T，三个字段 ，序号，物料类型，class类型（类需要大写Ddic设置）。 ，然后维护数据进去，
1 ROH zcl_material_raw
2 fert zcl_material_fin

在Java，net 这些语言中用xml文件来保存类似服务注册，SAP中用配置表的形式最方便了。

第四步， 创建简单工厂类
这是第一层的调用类，模式控制的核心代码定义在这一层，这个类讲实现根据物料动态创建物料子类类型，并实现多态的能力。该类定义为普通公共类，并创建一个Obj方法
该方法是根据物料号码，获取物料类型，从而获得对应的物料类的名称并创建累对象的实例，方法可以是静态类型方法（可以用=> 符号调用），再设定方法的入参为物料号，出参为类名字（定义类型为抽象物料类）
这个方法就是将其实例化然后作为返回值传出 实例化的对象都是物料类的可实例化的子对象类，然后赋值给父类物料类对象进行上转型，这就是典型的多态（动态）应用。代码如下↓，

第五步，创建最终调用程序

那么，简单的一个根据物料输出打印的框架构造完成了，对于这种简单的业务构造看起来可能觉得不必要，但是为什么要这样前面也说过了。我自己也有相对的理解，理论上原则来说都是为了 高效。那构造这个框架就像一个公司管理层，那对应的实现类就是下面的工作人员，随着公司发展壮大，工作人员会不停增加，可管理层结构不会发生太大变化，工作人员基数不停增长，可管理层还是那么些人 ，对于代码来说，我的框架已经定义好，这个业务场景不管是千种还是万种物料类型，都不会影响到我的管理层，越高层的人，管理和抽象能力就越越强就是不停开会开会，为公司指明发展方向和方法而不是去具体实现，业务实现层关注琐事。其次更是加大了迭代的安全性及维护成本，上面也提到如果核心人物离开，业务设计场景就是毁灭打击，一般人员不可能去进行后续维护，有了框架，只需要在对应的地方创建类，维护配置表的数据，怎么实现是开发人员的事情，这样只要会开发打印的人都能去进行后续修改，而不是原设计者或熟悉的人指导这个程序的业务场景有哪些，要在哪修改，那么这套框架就是对于这个业务场景的最佳实践 ，不需要去重新开发或者熟悉程序。。

三、 里氏替换原则（LSP）

1.概念

该原则有很多不同的理解，一般的解释 ： 子类对象能够替换父类对象，且保持程序逻辑不变。
从父类继承的子类如果是为了实现代码复用，则不应该去修改父类，当实际运用时，程序分别不出是父类还是子类对象，就不存在逻辑会改变了。 如果继承是为了多态的话，那么父类就应该是抽象类。 常常违背了这个原则的都是从实例化的父类中进行继承。

2.举例

有个很形象的例子，一个大巴车的类，有方法1.2 获取重量体积，方法三根据大巴车标准计算合格质量。 此时汽车类继承了大巴车类，那么在方法三的使用过程中就会出错，因为代码使用的是大巴车标准，还有修改方法1.2 测量汽车体积重要，并且大巴车类不是一抽象类。这就是很典型必须去修改父类的逻辑，不然就报错，修改了就违背了LSP原则。
这种解决的方法就是抽象出一个车类，只有一个方法1 计算质量。
子类大巴车类，汽车类继承车类，然后分别实现计算质量的代码。

符号LSP 原则的设计就是： 尽量不要从可实例化的父类中继承，而是尽量设计成抽象类或者接口。如果一个子类继承了父类，并且在子类对象在父类出现的地方出现原本没有的运行错误，那么就要考虑重新设计架构了。符合LSP原则是不会引入新错误的，这又是开发封闭原则的前提（只有符合了LSP，系统才可能符合OCP）。

四、 接口分离原则（ISP）

1.概念

接口分离原则很好理解，就是一个接口不应该负责多个类。每个类都要有特定的接口，因为接口中多余不需要的方法也要在类中进行罗列申明，如果不罗列就会有警告，这样会造成冗余混论不好维护。跟单一责任原则有相同，这个是针对接口的。要保证接口的颗粒度不能太大，也不能太小。

2.举例

五、 依赖导致原则（DIP）

1.概念

简单来说就是高层模块不能依赖底层的具体实现，要依赖抽象。

2.举例

六、 里氏替换原则（LSP）

1.概念

2.举例

---

总结