Класс с перечнем материалов: лучшие практики

Question

Я создал пользовательский класс ZMaterial, который можно создать, передав идентификатор конструктору, который устанавливает свойства для одного материала с помощью SELECT и BAPI. Этот класс в основном используется для чтения и обновления одного материала.

Теперь мне нужно создать сервис для возврата списка материалов. У меня уже есть процедурный код для него в статическом методе (на данный момент фактически в функциональном модуле), но я хотел бы продолжать использовать полный подход ООП и создавать список моего пользовательского объекта материала. Первый подход, который я нашел, состоит в том, чтобы улучшить статический метод для создания экземпляра списка моего единственного объекта материала после выполнения выборок, и у меня есть данные во внутренних таблицах, но это не похоже на ООП.

Второй вариант, на мой взгляд, заключается в создании нового класса ZMaterialList, в котором одним свойством является список объектов ZMaterial, а затем конструктор с необходимыми входными параметрами для выбора базы данных. Проблема, которую я вижу с этой опцией, состоит в том, что я создаю полный класс только для конструктора.

Как вы думаете, как лучше поступить?

Answer 1

Создайте отдельный класс для составления списка материалов. принцип одиночной ответственности гласит, что каждый класс должен делать только одно.Во всех случаях, кроме самых простых, , использующих вещь, является другой ответственностью, чем , производящий ее.

Не создавайте класс ZMaterialList.Фокусом списка будет управление элементами списка, т. Е. Добавление, удаление, итерация, сортировка и т. Д. Но у вас должно быть все в порядке с обычной стандартной таблицей REF TO ZMaterial.

Создайте ZMaterialReader, -Repository, -Queryили -Factory class или тому подобное, в зависимости от того, как именно вы хотите производить ZMaterials.Читатели читают по ключам, репозитории читают и пишут, запросы используют различные наборы критериев выбора, фабрики создают экземпляры с, возможно, различными наборами входных данных.

Вы можете позволить этому классу использовать исходную функцию FUNCTION внизу.Это хороший стиль, чтобы использовать то, что уже есть.Просто убедитесь, что вы доверяете этому коду, поместите его в тестовый комплект и держите его подальше от остальной части своего oo-кода.

Извлеките все общедоступные взаимодействия ZMaterial в интерфейс и используйте только этот интерфейс.Это позволяет предлагать альтернативные реализации ZMaterial, отличающиеся способом производства и хранения данных.

Разделение отдельного производства от массового производства.Чтение MARA для получения одного материала - это нормально.Но вы не хотите, чтобы тысячи ZMaterials читали MARA по отдельности - это снижает производительность.

Теперь, когда у вас есть интерфейс, вы можете предложить вторую реализацию ZMaterial, конструктор которого получает все соответствующие данные и уже полагается на них.будучи проверенным, чтобы избежать дополнительных SELECT.

Вы также можете предложить реализацию, которая вообще не хранит свои данные, а только хранит указатели на строки во внутренних таблицах где-то еще.См. Шаблон flyweight для идей.

Если вы ожидаете массовых обновлений материалов, таких как «переклассификация всех их как B», рассмотрите возможность выделения этих операций, ориентированных на список, в отдельные классы какхорошо.