Наследование с составом
Я проектирую систему, я еще не реализовал сначала, я просто строю ее диаграмму, а затем запишу ее, я хочу задать один простой вопрос:
Что делать, когда мы используем наследование и композицию одновременно?
Например, в отеле есть 2 вида номеров: стандартный номер и номер Твин, скажем так. Для этого я могу использовать концепцию наследования, и эти 2 вида комнат будут производным классом, но я также могу использовать композицию и составить отдельный класс для стандартных и двухместных номеров, а затем использовать этот класс моего отеля.
Что я должен делать?
Решение
Этот вопрос довольно расплывчатый, и многие детали отсутствуют, но я поделюсь некоторыми идеями …
Первое: во время работы над дизайном вашего приложения, самое главное, это требования.
Вы должны попытаться определить сущности, которые вначале будут иметь какое-то значение в вашей системе. Допустим, вы знаете, что там будет Гостиница а также Номер. Обратите внимание, что это отношение уже является композицией, главным образом потому, что:
- номер может быть частью только одного отеля, он не разделен между несколькими отелями
- как только отель разрушен, так же как и все номера в нем
в C ++ композиция обычно означает «по значению», т.е. class Hotel мог бы иметь Room room; это был бы объект с автоматической продолжительностью хранения с временем жизни, привязанным к времени жизни экземпляра Hotelс несколькими комнатами вы можете просто поместить их в вектор, получая одинаковые отношения:
class Room { ... };
class Hotel {
public:
std::vector<Room> rooms;
};
(Кстати, агрегация, скорее всего, будет представлена указателем или ссылкой). Это еще один хороший пример композиции:
Если вы знаете, что будут разные типы комнат, то первый вопрос должен быть следующим: будут ли эти объекты иметь разное поведение? будет ли моя система относиться к ним по-другому? … может быть, вам не нужно идти на более тонкую гранулярность, чем Номер и все, с чем конкретная комната будет специфична, будет выражаться с ее атрибутами — размером, количеством кроватей, может быть, десятки логических «имеет» флаги («есть кондиционер», «есть телевизор», «есть микроволновая печь», … ), может быть, все его свойства могут быть выражены простым «типом», значения которого вы бы поместили в enum,
Другие решения
В случае с вашим сайтом у меня будет свойство room_type для класса комнаты, и я установлю тип свойства room_type в перечисляемый тип с возможными значениями STANDARD и TWIN.
Пока нет существенных поведенческих различий в зависимости от этого типа поля, я бы оставил это простым.
Если существуют сложные способы поведения, такие как прогнозирование очистки на основе количества кроватей, изменение цен и т. Д., Я бы использовал абстрактный базовый класс CRoom и унаследовал от него CStdRoom и CTwinRoom, возможно установив постоянное свойство num_of_beds в конструкторах класса. ,
Не следует использовать наследование языка для моделирования наследования бизнес-требований. Это просто усложняет изменение или расширение бизнес-модели. Наследование языка предназначено для реализации функций вашей модели, а не самой модели.
Вместо этого извлекайте все ваши объекты из «бизнес-объекта» или аналогичного, чтобы инкапсулировать общее внутреннее поведение, такое как сериализация. Ваши классы могут иметь типы, и вы можете использовать typeinfo, или вы можете использовать явное поле типа. В любом случае ссылки между объектами, будь то наследственные или составные, должны быть указателями (или полями идентификатора индекса) и коллекциями (указателей или идентификаторов индекса). [Ваш фрагмент кода в порядке, но указатели усложняют управление памятью, которого избегают целочисленные идентификаторы.]
Сложное поведение должно принадлежать другим классам, таким как Ценообразование, Очистка и т. Д. Существуют и другие шаблоны, которые можно использовать для установки отношений между бизнес-объектами и бизнес-действиями, но опять же избегайте их кристаллизации с использованием языковых функций. Вы пожалеете об этом, если система вырастет или даже изменится.
detector