弗雷德，您好

对于UML工具，您可以使用Star UML，它很简单并且允许很长的试用期。

总有一种方法可以说，OO导致复杂性只是故事的一半。 在OO中设计解决方案更为复杂，但是出于灵活性，可维护性，具有自动化的单元测试等目的，我还是会选择在过程中始终采用它。

正确的OO需要更多技能，这是肯定的。 在这里，干净的代码适用于Bob叔叔所说的SOLID原则。 使用SOLID（单一职责，打开-关闭，liskov替换，接口隔离和依赖项反转）。 使用它，您可以进行可测试的设计。

设计模式可帮助我们实现SOLID。 很好地掌握他们的工作方式也有帮助。

让一个班级接受所有课程似乎在很大程度上违反了单一责任原则。 阶级责任真的需要全部吗？ 考虑一下您的类正在执行的所有"位"，然后开始将它们组织为"关注点"（其他类），将它们组织为更大的"关注点"（其他类），直到您进行设计为止。

拥有专门的课程应该导致更少的耦合，而不会更多。 也许您过于专注于将专业类中的内容"询问"为一个庞大的类，而不是设计类，而只是"告诉"他们该做什么。

没有全貌很难提供帮助。 对于复杂的解决方案，要有好的设计并不容易。 但我确定您可以做到！

最诚挚的问候，

Felipe Silva

有关我的问题的小消息。

实际状态是：

所以在我的最后一堂课 如果要调用方法Get_MM_info1，则必须执行

get_instance_mm_ca_data（）-> get_mm_info1（）。

代替go_mm_ca_data-> get_mm_info1（）。

问题是，我无法注入模拟，也许我将不得不使用双重框架。

积极的一点是，仅在需要时才创建DATA实例

我不明白为什么需要通过构造函数传递所有"注入器"。 您有以下可能性：

• 构造函数注入（您的操作）
• setter注入：在实例化之后，开始测试之前，调用setter方法来定义注入器。 因此，定义几种方法来传递不同的注入器。
• 后门注入：让测试类成为被测试类的朋友，以便它可以在测试开始之前更改私有依赖项属性。
li>
• 依赖关系查找：如果您具有实例化不同子类的工厂方法，则可以使用它，可以传递一个注入器选择器，该选择器在运行时选择正确的注入器。

在网上搜索 有关这些类型的注射的更多信息。

PS：在MOOC"为ABAP编写可测试的代码"中讨论过。

以我的观点，因为如果您有一个接口，则创建实现此接口的模拟程序非常容易和快速（并且更容易阅读）。 我真的不知道双重测试框架有什么优势...

嗨，弗雷德里克，

我不想阻止你。 如果您想培训OO设计，那么这是一种在功能性API之上构建干净的基于Code的OO层的好方法。

我过去看到的大多数OO设计都是由来自非OO业务的人们完成的，它们使用起来很恐怖。 商业利益（解决需求）最小，复杂性最大。

具有OO背景的人（例如WebDynpro ABAP，BOPF或/SCWM/CL * API）进行的OO设计往往很复杂，迟早与原始概念不一致。

我们在开发中承诺，我们不想发明除SAP外的其他（"更好"）ABAP OO框架。 根据我的经验，如果您尝试一下，最终将需要进行80％的OO兑换和20％的业务需求解决工作。

您是否有多个可注入类（例如ZCL_WAREHOUSE_DATA作为纯虚拟基础，为WM派生的ZCL_WM_CA_DATA和为EWM派生的ZCL_EWM_CA_DATA？

如果是这样，您是否已经具有一个注入器（汇编器）类，该类根据构造计划从所需的可注入实例中构成业务类实例？ 如何定义施工计划？ 通过"元语言"（也许通过数据库定制）进行通用或刚刚编码。

如果您开始思考并实现这一点，那么您将以80％的比例开始工作。 ;-)

写完此注释后，我意识到我只需要使用setter方法来注入该模拟即可。 我确定您会提醒我这种可能性:)