开发人员、技术顾问和SAP爱好者经常向我提出以下问题：

今天我将借此机会解释在ABAP中编码时应遵循的干净设计的几个方面，或者更确切地说，在ABAP中编码时应遵循的几个方面。

但在我继续之前，我想给你简单介绍一下ABAP的背景知识。当然，我们每个人都很清楚ABAP的历史。但我觉得在我们继续前进之前，这一点很重要。

最初的R/3天ABAP是作为一种过程语言开发的，零售大数据解决方案，与那个时代的其他过程语言不同。但是随着面向对象ABAP的引入，它已经适应了面向对象编程的原则。它现在类似于任何其他流行的面向对象的编程语言，如java或C++，因为它有诸如继承、多态、类和对象等概念。今天，面向对象的ABAP更经常地被用来简化整个编程模型。代码冗余最小增强的数据安全和访问可以从真实世界的实体中提取参照，并用于建模形成一个有效的编程结构。

说到这里，你们大多数人可能已经猜到了讨论的方向。

现在我们大多数人需要在这里开发一个类，然后支持各种业务目标。要做到这一点，我们中的许多人选择的最简单的方法是用静态方法创建静态类，并将我们的代码放入这些方法中，然后认为我们的工作已经完成了。

但是我们是否考虑以下几点：

好吧，回答第一个问题。不，我们没有遵循面向对象的行为。为了回答第二个问题，如果一个类有一个与之相关联的测试类，那么它的真实性是可以被证明的。此外，数据安全和访问为空。任何使用此类的实体都可以访问成员并更改其值。而且，OOPs的唯一目的是拥有成员函数，即对成员进行操作的方法。另一方面，从真实性的角度来看，在测试过程中不能为这个类创建和注入双重类

那么，我们如何解决这种情况呢？

始终将方法和属性定义为实例组件。只有真正需要时才使用单例模式。

这是一个比以前更好的设计，因为现在属性是私有的。因此，只有通过方法才能安全地访问类中的数据。所以现在我们限制了类的成员被任何消费者操纵。此外，由于没有静态方法，使用者需要生成一个实例来访问成员函数，即方法。因此成员函数被绑定到生成的实例。然而，设计仍然不够完美。请考虑以下情况。

一个用户类需要引用这个类。因此，在不更改用户类的情况下，不可能用另一个类替换这个类。从测试目的来看，双类必须是这个类的子类。因此，这个类不是最终的。

因此，可以通过引入一个接口来消除上述限制。用户类可以引用接口，从而具体说明所需的方法和属性。所有其他方法和属性都是私有的或受保护的，因此是隐藏的或抽象的。只有不可变和只读属性是公共的。

同样，淘客推广渠道，这是一个更好的设计，但不是很干净的一面。我们可以通过提供一个接口，由需要引用我们类的用户类实现，从而消除引用我们类的用户类的依赖关系。另外，根据测试目的，现在可以使用接口进行双重创建，这样我们的类就可以成为最终类了。

但是对于使用者类来说，对象创建是技术性的和复杂的，因为构造函数必须提供可选参数来允许创建不同类型的对象（用例）。如果构造函数包含所有的逻辑和依赖项，那么这些将成为每个单元测试的一部分，并且需要由子类double继承。此外，从构造函数的外观来看，我们无法确保类是否是单例的。

作为上述限制的救星，为每个对象类型提供至少一个创建方法将允许使用较少的（大部分是非可选的）参数创建简单易读的对象。为了强制独占使用创建方法，类的实例化需要私有化。另外，通过对创建方法的标记，我们可以清楚地表示要返回的实例是否为单例。[为单例实例获取，为非单例实例创建]

这是一个比我们开始时更好的设计。但是，在使用静态创建方法时，仍然存在来自类的直接依赖关系。如果许多类使用这个类，它们将使用提供的静态创建方法来实例化这个类。如果明天我们需要用其他类替换这个类，淘客app源码，那么需要修改所有的消费类。此外，用户类不能与双类协作进行独立测试。

因此，有享云商城，更好的设计是将该类的对象创建委托给工厂类。用户类不再是创建者。作为全球朋友，工厂类是唯一一个访问这个类的私有创建方法的类。

现在我们可以认为这是一个干净的设计，我们有工厂为我们提供不同场景的对象。另外，如果明天您的类需要更改，则需要在工厂中更改创建逻辑。因此，使用者类没有任何修改。