Форум PHP

Спасибо за ответ!

Дело в том, что Java более структурированный язык, чем PHP и менее специализированный, Java архетектуру требует, PHP - просит, чтобы от него отстали... PHP изначально заточен под совместное использование с HTML (HTML и PHP код идут вперемешку), ориентирован на сеть с её последовательным доступом (далеким от объектного взаимодействия), а также на базы данных, которые сплошь реляционные, ни одной объектной нет. Поэтому ООП-задачи тут встречаются не часто. Достаточно сказать, что ни по скорости выполнения, ни по структурированности PHP не подходит для объемных проектов, т.е. зачастую до задач, где реально ООП требуется дело не доходит - разработчики предпочтитают менять язык программирования.

>И ООП оправдывает себя когда и в плане отладке и редактирования, и когда строчек кода более
>1000!!!!!
Только PHP хреново в этом плане устроен - у него классы вырастают до 1000 строк кода и разрезать их на части, как в том же C++ нет никакой возможности, так и колупаешься в этих 1000 строках - одно спасение плодить сотни классов.

В любом случае, даже если вы решили использовать ООП в PHP-разработке не нужно совать его везде, как в C++ или Java, здесь это дорогое удовольствие. Да и в C++ и Java к этому вопросу нужно подходить с умом, иначе все классы можно связать в клубок, который от обычной процедуроной программы ничем отличать не будет - куча связей, ни один класс нельзя выкусить без того, чтобы он за собой не потянул всю программу.

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

Просто я изучаю ООП PHP, JAVA, C++, С# одновременно!!!!!! Первым делом я научился печать вслепую!!!!!!! Чтобы знать русский и английский язык, как свои десять пальцев!!!!!!

Я хочу строить на ООП, наследования, множественого наследования с использованием интерфейсов!!!!!!! В языке JAVA очень хорошо используется ООП, рефакторинг с использованием шаблонов(паттернов проектирования). И ООП оправдывает себя когда и в плане отладке и редактирования, и когда строчек кода более 1000!!!!!

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

Кто умеет программировать на ООП!!!!!!!! Покажите пожалуйста класс хотя бы с одной переменой, которая сохраняется в БД MySQL, при помощи введенной в эту форму и нажатием кнопке отправить!!!!!!