ООП ради ООП

#ооп #классы

Доброго времени суток!
Есть, к примеру, класс Cat, который реализует интерфейс Movable, инкапсулирует цвет
и прочее.    Имеет ли смысл создавать подклассы BlackCat, WhiteCat и т.д., которые,
по сути дела, ничего нового не привносят? Правильно ли в таком случае создавать enum
Сats и уже конкретный экземпляр enum'а (со своими полями) передавать в конструктор
класса Cat, а там присваивать значения полей?    

Ответы

Ответ 1

Переменные аспекты (условия/реализации или как удобней их называть) лучше всего всегда
отделять от тех, которые являются постоянными. Это правило как один из принципов проектирования.
Если следовать ему, то тут уж надо выделять отдельный интерфейс с реализациями цвета
или, как предложили, создать перечисление. Например, если цвет будет переливающимся
и становиться другим в зависимости от условий (допустим, от освещенности комнаты, где
находится кошка), то уже перечислением не обойтись, а надо делать интерфейс и реализовывать
отдельное поведение для отдельных цветов кошки.
В итоге у нас может получиться один абстрактный класс или интерфейс Cat с реализацией,
например, BadCat и GoodCat. Также будет интерфейс Colorable и конкретные реализации,
например, WhiteColor, BlackColor.


Ответ 2

Говорить о сферических котах Шредингера в вакууме довольно сложно, поскольку не факт,
что удастся перенести полученный в этом вопросе опыт в реальное приложение.

Есть ряд простых, которые могут сказать, стоит или нет использовать наследование,
или некоторый аспект должен быть лишь свойством.

Отношение "Является" против отношения "является свойством".

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

Или же можно сказать, что цвет - это один из атрибутов конкретного экземпляра, который,
к тому же, может поменяться со временем?

Поскольку второе высказывание кажется более логичным, то и предпочтение стоит отдать
свойству Color, а не подклассам BlackCat, RedCat и т.д.

У этого подхода есть ряд очень важных следствий.

Когда что-то моделируется с помощью класса, то созданный объект намертво к нему привязывается.
У созданного объекта кот нельзя поменять цвет, что вполне может быть реальным при моделировании
некоторого поведения (например, кот постарел, его обрили).

К тому же, иерархии плохо расширяются. Это значит, что для добавления нового цвета
придется изменять иерархию, что существенно сложнее добавления нового перечисления
или путем просто использования другого значения из стандартного перечисления Color.

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