| Дело в том, что Java более структурированный язык, чем PHP и менее специализированный, Java архетектуру требует, PHP - просит, чтобы от него отстали... PHP изначально заточен под совместное использование с HTML (HTML и PHP код идут вперемешку), ориентирован на сеть с её последовательным доступом (далеким от объектного взаимодействия), а также на базы данных, которые сплошь реляционные, ни одной объектной нет. Поэтому ООП-задачи тут встречаются не часто. Достаточно сказать, что ни по скорости выполнения, ни по структурированности PHP не подходит для объемных проектов, т.е. зачастую до задач, где реально ООП требуется дело не доходит - разработчики предпочтитают менять язык программирования.
>И ООП оправдывает себя когда и в плане отладке и редактирования, и когда строчек кода более
>1000!!!!!
Только PHP хреново в этом плане устроен - у него классы вырастают до 1000 строк кода и разрезать их на части, как в том же C++ нет никакой возможности, так и колупаешься в этих 1000 строках - одно спасение плодить сотни классов.
В любом случае, даже если вы решили использовать ООП в PHP-разработке не нужно совать его везде, как в C++ или Java, здесь это дорогое удовольствие. Да и в C++ и Java к этому вопросу нужно подходить с умом, иначе все классы можно связать в клубок, который от обычной процедуроной программы ничем отличать не будет - куча связей, ни один класс нельзя выкусить без того, чтобы он за собой не потянул всю программу.
Возьмите проблему и выстройте архитектуру/мини-язык. Не зачем моделировать базу данных и столбец при помощи ООП - они и так имеют отличный интерфейс. Возьмите пользователей, возьмите новость - создайте модель для них, возьмите HTML-форму, постройте расширяемую ООП-модель для неё, так чтобы можно было наследованием выстроить любую HTML-форму, которую душа пожелает. Соедините это в отдельный блок (не создавая для этого класса, если вы не будете от него ничего наследовать). В любом случае берите для моделей классов те понятия, которые отсутствуют и не реализованы - дублировать СУБД, или существующие интерфейсы не нужно, создавайте свой, язык, под свои задачи, причем, чтобы у классов была потенциальная возможность для наследования, чтобы через год-два унаследовав от них новые классы, можно было расширить их функциональность, не нарушив работы старых приложений. Вот тогда ООП окупится. | |