Модель обзор объект в пути объектно-ориентированный

Question

У меня есть API, который показывает, скажем, город:

/cities 
/city/{id} 

городов конечная точка возвращает обзор города (ID, название города, город область), тогда как конечная точка города возвращает тот же плюс еще несколько (население, изображение, миниатюра ...). Теперь, когда вы моделируете это в клиенте, я вижу разные альтернативы:

1. У вас есть класс CityOverview, в котором есть подкласс City, который добавляет дополнительные атрибуты.
2. Есть класс City, который имеет все атрибуты с подклассом CityOverview, который скрывает все дополнительные атрибуты (скажем, в Java, путем исключения исключения UnsupportedOperationException на всех геттерах для атрибутов, которых у него нет).
3. Имеют вышеуказанные классы без отношения наследования.
4. Имейте один класс города, который позволяет использовать все дополнительные атрибуты.

Каковы плюсы и минусы вышеуказанных утверждений и/или любого другого, о котором вы можете думать?

Answer 1

Я бы выбрал вариант 3 - имеет 2 класса, т. Е. а не отношения наследования. Вот причины для принятия этих решений:

• Вам нужно будет сериализовать \ serialize JSON с помощью api, такого как jackson. Для этого вам понадобится POJO с полем. Поскольку теперь у вас есть 2 отдельных класса, вы можете сопоставить различные POJO с двумя различными вызовами api. Это делает код чище.
• Наследование не является вариантом из-за 2 причин - 1). В один момент любой из ваших вызовов API будет либо передавать данные для родителя или ребенка. То есть поля либо всегда будут пустыми, в зависимости от того, какой API вы вызываете. Это ненужные отходы.
• 2). С точки зрения объекта ООП объект данных, возвращаемый в звонки в городах, равен , а не родительский элемент данных, возвращаемых в городском {id} вызове. Таким образом, мы не должны иметь этого в дизайне класса. Они вместе составляют сущность «Город».

Answer 2

Я думаю, что если между Обзорным городом и городом нет большой разницы, вы должны сохранить только один класс города в BE.

В вашем/city api вы можете передать полный список своих городов.
Отображение списка городов с несколькими подробностями в каждом городе (OverviewCity) может быть легко создано из объекта City на стороне клиента. В Backend я не думаю, что есть необходимость поддерживать 2 класса.