ну забил чувак на строгую типизацию. Зато FB ошибок не выдаёт при присваивании :-)))) если повсеместно такое насаждать.

Дело не в этом. это и есть пример плохого ООП
в хорошем (нормальном) конструкция
должна была сразу сократиться до
А то и вообще убрана или перенесена вниз по иерархии.

вот почему я не люблю (в большинстве случаев) динамические классы

Ну, имелось ввиду, что ты постоянно занимаешься флешем и постоянно черпаешь что то новое.)

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

В ТЗ обычно описан необходимый результат.
Дальше есть 2 типа программеров.
1) которые делают результат по ТЗ и дальше хоть, конь не валялся, и
2) которые знают что ТЗ поменяется скоро и придется переделывать ( или вообще такой вариант возможен).

Что это означает, я не понял?

Непереводимая игра слов некоторых народностей, означает примерно то же, что "хоть кол на голове теши" или" хоть партизаном назови" или даже " после нас хоть потоп" и самое интересное :" да мне побарабану"

Это я знаю :) Не понял высказывание в контексте поста.

Означает, что (1) пишет код так чтобы обеспечивать результат по ТЗ, как его дальше сопровождать, изменять, портировать, расширять - не волнует
(2) знает (или привык писать так) что код надо будет дальше сопровождать, изменять, портировать, расширять.
Вот в этом и разница хороший ООП и не хороший.
Все писать на ООП не обязательно. я еще раз повторюся, что КОНЕЧНЫЕ реализции могут быть (и часто являются) процедурными или функциональными.
Но что касается распределенной по времени и исполнителям разработки: ООП маст хэв.