Форум PHP

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

наверное, самое главное - это возможность повторного использования кода и расширения функциональности классов (это премущество :) )

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

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

И тут снова я влез :)
Это наверное сотая тема про ООП. Мне кажется надо сделать для этого 3-х буквенного сочетания исключение в поиске...

Один из серьёзно-оправданных случаев использование классов - использование в качестве пространства имён (контейнера для библиотеки)

Напрмер Вася написал кучу классных функций для работы с файлами и выложил у себя на сайте. Петя скачал файл, прикрутил файл к своему скрипту и полезли варнинги. так как Вася использовал в качестве названий функций те же имена что и Петя.
А если Вася оформит библиотеку в качестве класса, то ей смогут пользоваться миллионы страждущих без особого напряга.
Естественно если Вася внятно опишет интерфейс своего класса.

>А если Вася оформит библиотеку в качестве класса, то ей смогут пользоваться миллионы страждущих без особого напряга.

это несомненно удобно, чтото чужое прикрутить (например spaw), но вот я в своем коде (может потому что пишу для себя) ООП нигде не использую, незнаю почему.. какаято неприязнь у меня к нему :)

Вообще идеальный класс - это чёрный ящик.
Имеется входные параметры и имеется результат. Вся логика скрыта от любопытных глаз юзера. Это как телевизор. На вход подаём антену, на выходе имеем Петросяна. Как из куска провода получается юморист нам уже фиолетово. Нам важен результат.
А в отличии от функций результатов может быть несколько и разных типов. Т.е. это уже типа НПЗ. На входе подаём нефть на выходе получаем мазут, бензин, масло. Смотря к какому крану подойти.
Я раньше делал так (как делаю сейчас см. ниже):
Алгоритм.
1. Нужна довольно объёмная функуиональность, но самому писать лень или сроки поджимают.
2. Идём сюда: http://www.phpclasses.org/ смотрим список, находим нужный класс.
Там доволно хорошо задокументированы классы и легко разобраться что какой метод делает.
3. Скачиваем класс прикручиваем его в конфиг сайта и теперь в любом месте можем спокойно вызывать его методы не заботясь о конфликте имён.
Я пока слабо (см. вообще не :)) знаком с STL для С++ но сдаётся мне что это то же самое.
Вообще я обоими руками за повторное использование кода. Не надо изобретать табуретки, граждане. А то я смотрю каждый второй пишет свой фрейворк. Я по молодости тоже по-началу с шашкой наголо кинулся его писать, но потом остыл и занялся коллекционированием. Заказал себе рассылку с вышеозначенного сайта и теперь каждый день по 2 новых класса, с доставкой на дом. Понравится, в коллекцию, нет - в топку. На изучение одного класса уходит примерно 2-4 часа, зато теперь у меня есть код почти на все случаи жизни.

ну да ладно. Пора закругляться... А то щас про корабли бороздящие вселенную начну вещать :)

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

В 5 версии PHP появились абстрактные классы. И теперь ничто не мешает разделять чисто интерфейс и его реализацию по разным классам.

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

Вот тут немного непонятно.
Конечному пользователю интересны только public методы. А всякие служебные private пусть себе торчат в базовом классе.
А описание методов абстрактного класса это уж user guidе, без этого никуда. Тем более что всё описание сводится к строкам (прямо внутри класса в качестве комментов) типа:

/**      * Basic validation and parsing of a passed extensions parameter      *      * - This method does *not* check whether the extensions passed *are* real-life extensions,<br>      *         i.e. it does not spell check nor check against a list of 'known' extensions.      * - If no parameter is passed or the parameter passed is not a string nor an array      *         it defaults to the class default      * - If the passed $exts are the same as the last time this method was used, the check will      *             be skipped and the results of last time will be used for efficiency      *      * @access     private      * @uses     $last_passed_exts    for efficiency check / sets the variable if the current      *                                 passed $exts is different      * @uses     $last_exts            for efficiency if the passed exts were already checked /      *                                 sets this variable for same use if the passed $exts was      *                                 different      * @uses     $exts                to default to if no valid extensions parameter was passed      * @param    array|string    $exts    [optional] extensions parameter to validate      * @return    array|string    array of extensions or the string 'all'      */     function validate_extension_list( $exts = null )

которые в дальшейшем, с помощью phpDocumentatorа, сводяться в хороший help.

PS А что такое самодокументирующийся код?

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

Тогда непонятно зачем пишутся объёмные справочники по библиотекам того же С++ или Windows API
Там ведь тоже говорящие названия...

Затем же, зачем пишут комментарии к законодательству - законы же вообще то на русском языке написаны, только вы заранее не знаете без судебной практики как они себя в суде поведут и сколько нужно заплатить тому или иному судье, чтобы закон вёл себя так, как вам нужно :))) Там же и здесь вы можете догадываться подсознанием и догадываться правильно, но не составлять же индексный указатель по догадкам, легче это оформить в книгу и пользоваться ей.

У меня имеется справочник по Linux командам в бумажном виде, я с удовольствием им пользуюсь, хотя man, а уж тем более info более поный - на странице больше убирается текста, и русский текст со страницы я воспринимаю быстрее, чем английский с монитора. Тоже касается Windows API, да в заголовочных файлах вы найдёте много больше, чем в бумажных справочниках, которые устаревают, не успев быть выпущенными, но в справочниках приводятся примеры и патерны, которые работают и используются другими программистами, что в заголовочных файлах неприемлемо. Книги - это комментарии к излишне локаничным заголовочным файла, стандартам и мануалам.

axxil
>>>Там доволно хорошо задокументированы классы и легко разобраться что какой метод делает.
ГДЕ??? Че-то не нашел документацию ни для одного класса...

>ГДЕ???
Внутри самого класса.

Кстати , я оттуда скачал класс ArrayList, чего уж больно не хватало для ООП. Работает как класс ArrayList в Яве или его аналог в C#.
Это массив для управления объектами.
ООП на 5-м PHP вполне функционально, и можно собрать кое-что интересное, удобно разбив классы на категории: логические объекты, бизнес логика, база данных, ну и отделив интерфейс.

В приложении класс оттуда, сам комментарии не удалял, честное слово!
Сколько посмотрел - все так же задокументированы (закомментированы)...

Значит ответственные за рессурс, не следят за тем чтобы в присланных им классах были комментарии. А остальное зависит от программиста написавшего класс.
Тогда мне повезло больше, вот класс ArrayLIst ->

Значит все не так прекрасно, как описано axillом, ч.т.д.
ЗЫ: но на рассылку подписался, может действительно пришлют че ценного?...