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

Где то года 2 назад читал - там были какие то пункты вроде
- Все классы наследуются от Sprite, или от MovieClip - он как то привычней
- Вы не знаете что такое интерфейсы или не применяете их

И тому подобные. Тогда когда прочитал набрал от силы полпункта ) А чтобы получить зачет там надо было хотя бы 8-9. Статья потерялась, а в голове осталось. У кого нибудь сохранилась она, я найти никак не могу... Интересно, сколько пунктов наберу сейчас :)

http://riapriority.com/blogs/junik.p...oop_und_flash2 ?

Добавлено через 18 минут
ага, перечитал: на мой глаз актуально и сейчас
особо понравилась теза, что писать/проектировать надо как тебе удобно в контексте текущего проекта, т.е. ООП не догма, а очень удобный инструмент/способ облегчить себе жизнь

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

- это ересь?)))

что такое высокое зацепление и низкая связанность я тоже не в курсе

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

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

это противоречит их же пункту 8

"Повторное использование кода - это копирование целых классов и методов в новый проект с внесением незначительных изменений. А может и значительных, это как получится."

вероятно имеется в виду тяга бездумного избыточного наследования ради самого наследования, т.е. когда наследование происходит на уровне "смотрите, я наследую - у меня ООП!")))

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

>>хм... получается, что..

дык как раз наоборот получается: работает, устраивает - почему ересь?

silin, откуда вы ты это берешь? - по ссылке этого не было, вроде

там же целый базар-вокзал на тему..
ООП и Flash. Часть 3. О фанатиках, надо читать все для полноты картины, и коммменты тоже интересные, старое, но имо актуальное

да, еще: твой if (parent) parent.removeChild(this); безусловно удобная штука..,
но что-то типа parent.parent.mc это уже путь к гемору и неразберихе: видимо это имелось ввиду..

Да, оно, спасибо )
Player extends Airship extends RotativeObject extends FlyingObject extends Sprite3D

5. Теперь объясните мне, что в этом плохого. В игре есть другие Airship`s, которые не игрок, есть вращающиеся объекты, а есть просто статичные летающие, и все экстендится от Sprite3D. Что плохого? Или речь исключительно о наследовании ради наследования?

Если наследование ради наследования, то прошел по 9.5 пунктам. Ушел смотреть что такое
Добавлено через 9 минут
Почитал =) Использую, но не знал что это так правильно называется) Похоже, набрал все 10. Круто :)
Прочитал фанатизм. Есть чуть-чуть :)

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

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

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

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

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

Да, ересь.

каюсь)))

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

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

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

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

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

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

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

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

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

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

- практика показала, что нет.
Если метод однозначно нужен всем детям и не намечается его переделка под конкретных детей, то пихаю его в родителя. Если что, спустить вниз тоже не проблема. Всё происходит без фанатизма. :D

Наверное то, что я представил себе в голове – страшней реальности ^_^

И по теме топика:
А по теме – а какая по вашему объективная польза писать 100% ООП код?

Никакой. Но он должен быть таким, в среднем, по моему мнению, процентов на 80.