我已经创建了自定义类ZMaterial，它可以通过向构造函数传递ID来实例化，该构造函数使用SELECTs和BAPI为单个材料设置属性。这个类基本上用于读取和更新单个材料。
现在我需要创建一个服务来返回材料列表。我已经在一个静态方法(现在实际上是一个函数模块)中有了它的过程代码，但我想继续使用完整的OOP方法，并实例化我的自定义材质对象的列表。我发现的第一种方法是增强静态方法，在执行选择后实例化我的单个材料对象的列表，并且我在内部表中有数据，但这似乎不是最OOP的方法。
我心目中的第二个选项是创建一个新的类ZMaterialList，其中一个属性是对象列表ZMaterial，然后是一个具有数据库选择所需输入参数的构造函数。我看到这个选项的问题是，我只为构造函数创建了一个完整的类。
你认为最好的方法是什么？
创建一个单独的类来生成材料列表。单一责任原则规定每个班级应该只做一件事。除了最简单的情况外，使用一件事与生产是不同的责任。
不要创建ZMaterialList类。列表的重点是管理列表项，即添加、删除、迭代、排序等。但您应该可以使用常规的参考材料标准表。
根据您想要生成ZMaterials的精确方式，创建一个ZMaterialReader、Repository、-Query或-Factory类或类似的类。读卡器按键读取，存储库读写，查询使用不同的选择标准集，工厂使用可能不同的输入集实例化。
您可以让该类使用下面的原始FUNCTION。利用现有资源是一种很好的风格。只需确保您信任该代码，将其放在测试工具中，并使其与其他oo代码保持距离。
将ZMaterial的所有公共交互提取到一个接口，并仅使用该接口。这允许您提供ZMaterial的替代实现，这些实现在生产方式或存储数据的方式上有所不同。
将单一生产与大规模生产分开。阅读MARA以检索单个材料是可以的。但你不希望成千上万的ZMaterials单独阅读MARA——这会破坏性能。
现在您已经有了接口，您可以提供ZMaterial的第二个实现，它的构造函数接收所有相关数据，并依赖于已经验证过的数据来避免额外的SELECT。
您还可以提供一种实现，它根本不存储数据，只存储指向其他地方内部表中行的指针。有关想法，请参阅蝇量级模式。
如果您希望对材质进行大规模更新，例如"将所有这些重新分类为B"，请考虑提取这些面向列表的操作来分离类。