Что делать со сгенерированными во время выполнения данными, охватывающими несколько классов?

Question

Я программист-самоучка, и многие проблемы, с которыми я сталкиваюсь, связаны с отсутствием формального образования (и часто также опыта).

Мой вопрос в следующем: Как рационализировать, где выхранить данные, которые создает класс или функция?Я приведу простой пример:

Дело: У меня есть интернет-магазин (SHOP) с API-интерфейсом REST и провайдером продуктов (PROVIDER) также с API-интерфейсом REST.Я определяю продукт, я отправляю эти данные PROVIDER, который отправляет мне обратно отформатированные данные, которые могут быть прочитаны SHOP для создания рабочего продукта в интернет-магазине.У ПРОВАЙДЕРА также есть вторичный API REST, который предоставляет сгенерированные изображения.

Что бы я придумал: Я бы сделал три класса: ProductBase, Shop и Provider
ProductBase - это класс, из которого я создаю экземпляр и храню информацию об отдельном продукте.
Shop - это место, где я проектирую взаимодействия API с интернет-магазином.
Provider то же самое, что и магазин, но длявзаимодействие с провайдером api.

Моя проблема: В какой-то момент вы создаете данные, которые четко не разделены по интересам.Например: сохраню ли я сгенерированные данные о продукте (из PROVIDER) в созданном мной экземпляре ProductBase?Такое чувство, что я соединяю два класса таким образом.Но это не там, тогда где?
Что, если я создаю изображения продуктов с помощью PROVIDER и загружаю их в SHOP?Хранить загруженный URL-адрес изображения в PRODUCT?Как вы отслеживаете всю эту информацию?

На вопрос, на который я хочу ответить:
Я много читал об ООП и шаблонах проектирования, и я применил подход TDD, который очень помог улучшить мой код, но яничего не нашел о том, как приблизиться к потоку во время выполнения сгенерированных данных в разработке программного обеспечения.

Как можно было бы решить вышеуказанные проблемы, и не могли бы вы объяснить свое обоснование для этого?

Answer 1

Если я правильно понимаю, я думаю, что ваша текущая проблема заключается в том, что у вас есть «необработанные» данные о продукте, которые вы хотите сохранить в объектах, и вы «обработали» (отформатированные) данные о продукте, которые вы также хотите сохранить в объекты. Ваш вопрос заключается в том, чтобы смешать их.

Позвольте мне сначала указать на другой очевидный вариант. А именно, имея два класса продуктов: RawProduct и ProcessedProduct. Что делать?

(Изменить: также, чтобы убедиться, что данные продукта не должны храниться в поставщике. Поставщик выполняет форматирование, но данные - это данные продукта. Не данные поставщика).

Это зависит. Есть несколько соображений:

1) В общем, в ООП идея состоит в том, чтобы связать действия над данными с данными. Поэтому, если возможно, у вас есть некоторый метод в ProductBase, например, «format ()», где format отправляет объект в API для форматирования и сохраняет результат в переменной экземпляра. Затем вы также можете иметь метод, подобный «find_image», который отправляет и получает URL-адрес изображения из API, а затем сохраняет его в поле. Данные объекта должны быть динамическими. Он предназначен для изменения объектными методами.

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

3) ОЗУ беспокоит? Иногда я создаю классы данных, в которых хранится только последняя часть жизни объекта, чтобы я мог разместить больше объектов в памяти.

Лично я часто нахожу себя создающим классы "RawObject" и "ProcessedObject", это просто легче в большинстве случаев. Но это, вероятно, потому что я в основном работаю с обработкой документов, так что это очень ясно. Обычно вы просто обновляете данные объектов.

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

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

Как только ваши данные сохранены в объекте продукта, все может содержать ссылку на это. Таким образом, магазин может ссылаться на объект, а продукт может ссылаться на объект. Проясните разницу между отношениями «есть» и «есть».