ООП ради ООП

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

0

Сообщение от Recreate класс Cat который реализует интерфейс Movable, инкапсулирует цвет, и прочее. Имеет ли смысл создавать подклассы BlackCat, WhiteCat

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

1

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

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

0

Сообщение от Recreate Препод говорит, что чем больше классов тем лучше.

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

0

Сообщение от Recreate Так вот я тоже этого не понимаю. Препод говорит, что чем больше классов тем лучше.

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

0

Сообщение от Recreate Так вот я тоже этого не понимаю. Препод говорит, что чем больше классов тем лучше.

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

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

Вполне.

0

Сообщение от korvin_ Классов должно быть ровно столько, сколько нужно для решения задачи (google: Бритва Оккама)

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

0

0

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

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

0

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

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

0

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

Добавлено через 1 минуту

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

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

Добавлено через 1 минуту

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

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

0

Сообщение от taras atavin Ту путал объекты со структурами и классы с пространствами имён.

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

0

Сообщение от Recreate Создавал объекты имеющие только состояние и ни капли поведения. Чтобы управлять ими создавал сервисные(менеджер) классы, которые собственно производили какие-то расчёты и прочее. И тут вдруг мне говорят что это не правильно.

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

0

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

0

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

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

0