Помогите найти: 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. Круто :)
Прочитал фанатизм. Есть чуть-чуть :)

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

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

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