@Recreate

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

0

quwy

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

1

@Recreate

Так вот я тоже этого не понимаю. Препод говорит, что чем больше классов тем лучше. Я решил создать enum в котором перечисляются типы кошек с предустановленными цветами и прочими свойствами. Потом в конструктор класса Cat помещаю конкретный тип и всё работает. Правильно ли так делать?

0

@korvin_

Классов должно быть ровно столько, сколько нужно для решения задачи (google: Бритва Оккама) и иерархия классов выстраивается исходя из требований к модели. Если требуется смоделировать поведение кошек в зависимости от цвета, то вполне логичным будет создать классы под разные окрасы (или виды окрасов, в зависимости от), в противном случае достаточно обойтись свойством «Цвет» в базовом классе и не плодить цветовые подклассы понапрасну, т.к. они избыточны.

0

@taras atavin

Но не так же! Можно в новых классах инкапсулировать цвет в других цветовых моделях. Например, базовый RGB, а потомки один захватывает ультрафиолет, расширяя модель до пяти плоскостей (Red, Green, Blue, Near Ultra Violet, Far Ultra Violet), другой хранит спектр видимого цвета через каждые два килоГерца, третий хранит оттенок, яркость, насыщенность, в четвёртом цвет субтрактивен. А значения цвета по классам раскидывать не нужно.

0

quwy

Если вопрос стоит так, то лучше углубиться в наследование "вертикально", чем плодить однотипные сущности "горизонтально". Сделать базовый класс ЖивоеСущество, от него унаследовать класс Животное, от него унаследовать Млекопитающее, от него унаследовать Кошачее, и уже от него унаследовать Кошку. И каждый тип функциональности реализовывать на максимально пригодном для него предке.

Вполне.

0

@taras atavin

А если его тренируют создавать классы без относительно дальнейшего применения? Просто чтоб запомнил, как это делается, а когда будет нужно, уже привычно создал классы.

0

@pycture

0

@korvin_

И как он узнает, когда нужно, если его не учили различать, когда нужно, а когда — нет?

0

@Recreate

Дело в том что в дальнейшем эти классы используются. И перспектива создания по классу на кошку меня самого не удовлетворяет(предки кошки ЧёрнаяКошка и т.д. абсолютно пустые т.к. нет новых свойств что логично и поведение то же самое). Куда легче иметь один класс и не думая что это за кошка использовать его. + в моём случае проверок будет меньше, соответственно читабельность кода будет выше.
п.с. Я около года изучал программирование в полном вакууме и раньше особо не задумывался над ООПшностью. Создавал объекты имеющие только состояние и ни капли поведения. Чтобы управлять ими создавал сервисные(менеджер) классы, которые собственно производили какие-то расчёты и прочее. И тут вдруг мне говорят что это не правильно. В таком случае из объекта выходит какая-то помойка.

0

@taras atavin

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

Добавлено через 1 минуту
Вот именно поэтому и надо для каждого класса сразу же придумывать, чем он будет отличаться от остальных типов, а не переменных.

Добавлено через 1 минуту
Ту путал объекты со структурами и классы с пространствами имён.

0

@Recreate

Прошу прощения. Я пишу на Java. Там нет структур. Насколько я понимаю структура это тот же бин, т.е. класс включающий только поля и методы доступа к ним. А пространство имён в Java это пакет...тут я уже не могу провести аналогию.

0

@korvin_

Это не неправильно, это другой подход, вот и всё.

0

@Recreate

Вообщем послушав всех отписавшихся я сделал для себя вывод что: ненужно создавать класс/наследоваться от класса если он не обладает каким-то отличным от предка/других классов состоянием или поведением.

0

@taras atavin

Только поля без методов и операторов. На паскале она зовётся записью. Объектный подход заключается в объединении данных и обрабатывающего их кода, всё остальное - не ООП.
1. Класс должен быть категорией объектов.
2. Объединение объектов в класс должно быть закономерным и вытекать из общих для этих объектов свойств, причём, значимых для задачи, причём, значения чего либо не учитываются, учитывается диапазоны представимых значений, способы их интерпретации и операции над ними.
3. Ни один другой класс не должен объединять объекты с тем же набором значимых для задачи свойств, причём, значимых для задачи, причём, значения чего либо не учитываются, учитывается диапазоны представимых значений, способы их интерпретации и операции над ними.
"Белый кот" - не класс, а объект с определённым значением поля, а "летучая мышь" - это класс, отличный от класса "кот". Потому что может летать и владеет локацией. Или тот же кот, но с иным внутренним представлением полей. Или с иным набором полей, методов и операторов-членов, значимых для другого класса задач. Некоторые классы вообще не должны встречаться в одном и том же проекте, другие должны участвовать в отношении "предок-потомок", третьи имеет смысл иметь одновременно в одном проекте, но в виде взаимонезависимых.

0