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