Дизайн / Архитектура для многих экземпляров ООП (или другой) реализации

Question

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

API предоставит серию тестов для каждогосистема.Каждая система будет представлена ​​как класс (со свойствами и методами), и все системы будут наследоваться от базового класса (GenericSystem), который будет содержать базовую, общую информацию о системе (IE dateOfCreation, авторы, systemType, имя, технология, владелец,и т. д.) Каждая система имеет много экземпляров, и каждый экземпляр имеет уникальный идентификатор.Данные о каждом экземпляре системы хранятся в разных базах данных, поэтому API будет местом, где все пользователи смогут одновременно найти информацию об этих системах.Вот требования:

1. Мы хотим, чтобы каждый пользователь мог создавать экземпляр системы (например, класс SystemName) и иметь возможность получить некоторую информацию о нем.

2. Мы хотим, чтобы каждый пользователь мог создавать несколько экземпляров системы (или GenericSystem) и получать информацию обо всех них одновременно.(Это должно быть эффективно. Только один запрос, а не один для каждого экземпляра).Поэтому мы подумали, что нам может понадобиться создать класс MultipleSystemNames, который будет реализовывать все эти методы множественного подхода. Это наиболее сложное требование, как кажется.

3. Мы хотим, чтобы данные были заполнены и кэшированы в свойствах и методах экземпляров.Поэтому, если я создаю экземпляр SystemName и вызываю systemNameInstance.propertyName, он будет выполнять необходимые запросы и заполнять данные в propertyName.В следующий раз, когда пользователь вызовет это свойство, данные будут немедленно возвращены.

4. Последний, должен быть сохранен подход единого системного класса .Каждая система должна быть представлена ​​как единая система.Позже мы можем создать класс MultiSystem, если это необходимо (для требования 2), но в его самой базовой форме каждая система должна быть представлена ​​отдельно (надеюсь, вы понимаете, о чем я).

Втораяи четвертые (2,4) требования - это те, которые мы действительно пытаемся выяснить.Должны ли мы использовать класс MultiSystemNames для каждого класса, а также для GenericSystem (MultiGenericSystems)?Мы не хотим усложнять пользователя и себя.

Знаете ли вы какие-либо ООП (или другие) лучшие практики чистым и упрощенным способом?Мы что-то пропустили?Извините, если я добавил некоторую ненужную информацию, но я действительно хотел дать вам представление о том, как мы хотим, чтобы все было.

Если вы уже достигли или нет, спасибо!

Answer 1

Система и экземпляр представляют одно и то же мышление, но используются в разных контекстах. Неважно, как вы храните или извлекаете их. Поэтому, если вам нужна коллекция System, вы просто используете собственную структуру данных коллекции (например, List, Queue, Map in java). Операции, связанные с Системой / Списком, должны быть отделены от POJO. Это означает, что вы внедряете их в сервисы, репозитории и т. Д. То, как вы храните и извлекаете данные, не должно влиять на то, как вы проектируете свои структуры данных. Вы достигаете производительности, применяя различные методы и / или используя надлежащие технологии, например, кеширование, использование хранилищ значений ключей или баз данных nosql, денормализацию таблиц реляционных баз данных и / или использование индексов и т. Д.