Помогите найти: 10 причин что вы пишите не ООП-код

[orcpochta]

Сообщение от silin

да, еще: твой if (parent) parent.removeChild(this); безусловно удобная штука..

на самом деле так лучше не делать в больших проектах, ибо если кто-то попытается удалить дисплейОбджект как положено через removeChild(obj) после вызова метода destroy, то получит "ArgumentError: Error #2025: The supplied DisplayObject must be a child of the caller."

а метод destroy пусть лучше внутренние слушатели отцепляет и наружу не лезет)))

[etc]

Сообщение от orcpochta

хм... получается, что для дисплэй обджектов
- это ересь?)))

Да, ересь.

[orcpochta]

Сообщение от etc

Да, ересь.

каюсь)))

[Psycho Tiger]

Сообщение от lowka

Иногда бывает более уместна некая компонентная модель, в которой сам объект есть набор компонент, определяющих его свойства и т.п.
А подобная цепочка классов в итоге дает лишь головную боль, когда оказывается, что функционал, предоставляемый одним из классов цепочки, необходим в абсолютно стороннем классе. Ошибка проектирования в данном случае налицо.

Ошибка проектирование налицо, если какому-то классу нужен весь функционал другого класса и это "оказывается".

lowka, а какие ваши предложения? Забить на наследование в моём случае и композицией/созданием новых методов собирать пару десятков методов со всех классов, а класс экстендить сразу от Sprite`а, чтобы хорошо было?

[Division]

ИМХО перед тем как наследовать что-то, нужно хорошо подумать. Действительно ли оно надо? Сейчас использую такой вот подход к архитектуре игр: немного изменённый паттерн декоратор. Можно наращивать функционал без наследования. Пишу вот и радуюсь (:

[lowka]

Сообщение от Psycho Tiger

lowka, а какие ваши предложения? Забить на наследование в моём случае и композицией/созданием новых методов собирать пару десятков методов со всех классов, а класс экстендить сразу от Sprite`а, чтобы хорошо было?

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

[Psycho Tiger]

Хорошо, дайте хорошую статью на ваш взгляд? Буду благодарен.

[$mival]

почитал, вроде все норм )

[Iv]

Сообщение от CrazyFlasher

"Вы часто используете наследование. В ваших цепочках наследования порой насчитывается более 5 классов."

что в этом плохого?!

- в этом ничего плохого нет, если это оправдано.

Как и любой инструмент, наследование нужно использовать с головой, понимая, к чему это приведет.
Длинная цепочка наследования чревата чрезмерным раздутием функциональности класса, превращая его реализацию в антипаттерн "Волшебная кнопка".
Как это узнать?
Плохой запах, на который следует обратить внимание - объекты конечного класса обладают избыточным функционалом и часть его публичных методов вы не используете никогда. Вы их просто унаследовали и спрятать не можете.
Запах становится еще четче, если вы вынуждены перекрывать унаследованные публичные методы новыми пустыми методами.

Чтобы на это не нарываться, я программирую снизу: сначала создаю конечные классы, если потребуется активно используя копи-пасту. Добиваюсь нужной функциональности, и только затем начинаю выносить общую функциональность в надклассы.
Этого пока хватало.

[Nirth]

Чтобы на это не нарываться, я программирую снизу: сначала создаю конечные классы, если потребуется активно используя копи-пасту. Добиваюсь нужной функциональности, и только затем начинаю выносить общую функциональность в надклассы.

Эххм, а это не классифицируется, как потеря времени )?