Форум PHP

Добрый день! Понемногу осваиваю ОПП и появляется много интересных вопросов: как я понял суть инкапсуляции это "Упрятать всё в класс". Например:

class item{        private name;                 private price;        function getName(){        return $this->name;        }        function getPrice(){        return $this->price;        }           function getName($newPrice){        $this->name = $newPrice;        } }

и давать доступ "методами"? да? И только если нужно, давать метод для изменения? Причем лучше называть методы для "получения" с приставкой get а изменения с "set" ?
Я правильно понял суть инкапсуляции? Просто всё запутанно так, но... блин интересно)

Да правильно. Более того, захотите потом отформатировать цену это можно будет легко сделать в одном месте, в методе getName() и изменения распространяться на весь код, в котором участвовал класс (не придется его перелопачивать). Более того, в цивилизованных языках у вас есть возможность видеть только названия методов класса, т.е. вы физически можете не видеть как класс устроен. В PHP, к сожалению, в этом плане инкапсуляция здорово нарушена - нужно лазить в класс, чтобы поглядеть на названия методов, а за одно и смотришь реализацию метода, что очень здорово бьет по инкапсуляции, так как невольно начинаешь учитывать реализацию метода в клиентском коде, а ведь реализация может со временем измениться.

Вообще по уму, конечно, нужно использовать механизм документации вроде javaDoc, только кто ж его использует... так все и лазят в класс, разбираясь как он работает. К сожалению, в PHP класс даже нельзя на части разбить - он должен быть в одном файле. Всех лучше реализована инкапсуляция в C++, вы можете объявить класс в заголовочном файле (h), объявив лишь прототипы, а реализацию класса поместить в другие файлы (cpp). Более того, вы можете откомпилировать cpp файлы или вообще оформить в виде статической или динамической библиотеки, оставив текстовым только h-файл. Т.е. разработчик даже физически не сможет посмотреть как класс устроен, зато может воспользоваться его открытым (public) интерфейсом. Отсутствие этого в PHP не вероятно бесит, почти весь ООП-код бесполезен, так как разработчики даже не ставятся в условия реальной инкапсуляции, когда вы не видите ничего, кроме интерфейса класса.

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

Вы обобщаете свой личный опыт на всех. Я же, напротив, регулярно вижу поддержку phpDoc --- это является одним из требований к коду для большинства современных фреймворков (Kohana, Symfony, Zend Framework, Yii, ...). Вероятно, вам просто следует задуматься над качеством кода, с которым вы работаете.

> Отсутствие этого в PHP не вероятно бесит, почти весь ООП-код бесполезен, так как разработчики даже на ставятся в условия реальной инкапсуляции, когда вы не видите ничего, кроме интерфейса класса.

Что, простите?

>Вероятно, вам просто следует задуматься над качеством кода, с которым вы работаете.
По качеству документации вы сильно не по адресу. Документацию следует составлять систематически (как например, мы это делаем выпуском книг или внутренней документации, которая изначально спроектирована как документация, а не как свалка комментариев). Многие ли книги выпускают по своему коду? phpDoc в реальности выглядит довольно уныло, поддержку phpDoc добавляют, но не сопровождают и справочные системы не собирают, а когда собирают - проще лезть в код, чем пользоваться тем, что получается. Если уж говорить о качестве, то сами разработчики крайне плохие кандидаты в составители документации, в силу того же принципа нарушения инкапсуляции (голова не тем забита в момент составления комментариев). В противном случае документация больше напоминает записки разработчиков самим себе, а не документацию. К тому же phpDoc проект не официальный, в официальной документации нет рекомендаций, нет стандартной утилиты, поэтому из реальной практики до генерации документации дело доходит действительно редко и пользоваться тем, что получилось почти невозможно. Документацию нужно писать отдельно, возможно опираясь на результаты phpDoc.

>Что, простите?
На форуме не принято вступать в неконструктивную полемику, если у вас другая точка зрения просто помещаете развернутый ответ ниже. Реплики в стиле "Чё?", "Нах", "Ну, бля" и прочие не допускаются. Если что-то не понятно, задавайте конкретный вопрос.

> Про качество документации вы сильно не по адресу.

Я вообще ничего не говорил про документацию. phpDoc в данном случае используется для автокомплита --- необходимого инструмента для отсутствия необходимости залезать в код. Его поддерживают все современные IDE --- будь то NetBeans, PhpStorm, Aptana, Zend Studio, whatever. Как следствие, вам не нужно "лазить в класс, чтобы поглядеть на названия методов".

Я даже скажу больше: если вы активно используете интерфейсы в сигнатурах (type hinting) и/или phpdoc, то сказать сходу какой конкретный класс используется в runtime нельзя: при Ctrl + левый клик мыши вы попадёте в описание интерфейса --- это, кажется, должно вам помочь. Три раза в день после еды.

И хорошо, коль так. Досадно, что в составе PHP нет стандартной консольной утилиты, которую бы можно было сразу вешать на cron-задание (может в PEAR что-нибудь есть, конечно, нужно порыться).

> Досадно, что в составе PHP нет стандартной консольной утилиты, которую бы можно было сразу вешать на cron-задание (может в PEAR что-нибудь есть, конечно, нужно порыться).

Не очень понимаю: как это относится к данной теме? Три раза в день?

>Не очень понимаю: как это относится к данной теме?
Так сложилось, что PHP-приложения распространяются и используются главным образом в виде исходных кодов. В результате у вас нет байт-кода или бинарных модулей (байт-код скорее исключение, чем правило), хотите вы или не хотите вы имеете дело с исходным кодом. Так получилось, что PHP изначально не поддерживал объектно-ориентированные возможности, они были добавлены сильно позже, когда он здорово распространился и нужно было поддерживать старый код. Кроме того, ООП был заимствован почти без адаптации, если не сказать без понимания принципов ООП. Просто добавили инструменты, ну нужны они вам, нате... Как результат поддержка инкапсуляции на уровне языка PHP слабая, если не сказать никакая (особенно по сравнению с языками, которые изначально задумывались как объектно-ориентированные). Я только это и хотел сказать: раздражает необходимость самому заботится об инкапсуляции (это можно делать не только внешними инструментами, но и ООП-средствами, только платить придется временем и кодом). Вы я так понял возражаете против этого, говоря, что не так все печально и даже наоборот с ООП в PHP все замечательно? Или вы хотите какую-то другую мысль донести?

Я повторю свой вопрос: причём тут консольная утилита, "которую бы можно было сразу вешать на cron-задание"? Впрочем, судя по мату, вы отмечаете какой-то праздник. Можете не отвечать.

> Вы я так понял возражаете против этого, говоря, что не так все печально и даже наоборот с ООП в PHP все замечательно?
Терпимо. Но PHP я не люблю.

>Я повторю свой вопрос: причём тут консольная утилита, "которую бы можно было сразу вешать
>на cron-задание"?
При том же при чем phpDoc: не причем. Не удобно и все. ООП-программы можно создавать вообще не пользуясь специальными возможностями языка и ключевыми словами. Однако, если объектно-ориентированная модель необходима в приложении зачастую более удобно воспользоваться другими инструментами, с более развитыми и удобными средствами, чем в PHP, который спроектирован не совсем удачно.

Безусловно, PHP изначально спроектирован неудачно. Но не я упомянул javaDoc, не я начал некорректные обобщения. Смиритесь с тем, что существуют отличные от вашей точки зрения --- не стоит так раздражаться.

P.S. phpDoc уже стандарт де-факто, это, не побоюсь этого выражения, практически часть языка (рефлексия в PHP уже позволяет доставать doc-блоки, благодаря чему можно встраивать мета-информацию прямо в phpDoc: http://docs.doctrine-project.org/projects/doctrine-orm/en/2.0.x/reference/basic-mapping.html --- очень удобно). Вы застряли в прошлом, сегодня существует множество решений для облегчения жизни PHP-программистам.

>Смиритесь с тем, что существуют отличные от вашей точки зрения --- не стоит так раздражаться.
Да это я понимаю и принимаю, меня раздражает, что я никак не могу уловить точку зрения. Я говорю что ООП в PHP дрянь (его недостатки перекрывают достоинства), идет возражение, нет не дрянь, точнее дрянь, но не такая дрянь, которую вы имели в виду. Это и не понятно.

>Вы застряли в прошлом, сегодня существует множество решений для облегчения жизни PHP-
>программистам.
Будто вы не обобщаете :) Да конечно, существуют решения (их на PHP слишком много), однако, существуют и другие языки, в которых можно не использовать костыли. Пусть существуют и решения для облегчения жизни PHP-программистам, я не против. Однако, если есть более удачный инструмент и я умею им пользоваться, я лучше его в руки возьму, чем будут бороздить Интернет в поисках "практически части языка", которая в язык не входит :)))

>рефлексия в PHP
Это есть, тут даже не в phpDoc дело, а в том, что рефлексия действительно стандартна и позволяет выделить интерфейс класса. Но это реализовать можно только на уровне систем вроде IDE, т.е. если вы не пишите систему сопоставимую по объему, где код, обслуживающий рефлексию будет занимать лишь несколько процентов проекта, тогда да. Если у вас обслуживание ООП-модели будет занимать 50% проекта, может ну-ка нафиг такую модель?

> Будто вы не обобщаете

Говорю про вас, утверждаю, что существуют такие-то решения --- я не вижу обобщений. У вас матан был?

> Я говорю что ООП в PHP дрянь (его недостатки перекрывают достоинства), идет возражение, нет не дрянь, точнее дрянь, но не такая дрянь, которую вы имели в виду

Я возражал совсем не против этого утверждения, я возражал против обобщения того, что все лезут в код --- это неправда (абсолютно все мои знакомые используют phpDoc для того, чтобы не лезть в код --- это непосредственно связанные между собой темы). Факт: не все лезут в код, даже если phpDoc вам кажется неудобным --- это не отменяет этого факта. Это единственное, с чем я изначально не согласен.

Если вы начнёте меня спрашивать про политику или религию, то я не сомневаюсь, что вы найдёте ещё достаточно много мнений, перпендикулярных вашим. Я не советую --- это пустая трата времени.

P.S. Весь наш разговор начинается сводится к тому, что я оправдываюсь: "нет, я это не говорил" --- желательно прекратить видеть в моих утверждениях то, чего там нет.

> Но это реализовать можно только на уровне систем вроде IDE

Не понял. http://ru.php.net/manual/en/reflectionproperty.getdoccomment.php --- я про это.

Возможно я не очень понятно выражаюсь... когда я пишу "Отсутствие этого в PHP не вероятно бесит, почти весь ООП-код бесполезен" я имею в виду вот что. ООП-модель PHP побуждает разработчика создавать развитую модель коротких классов, увязанных в иерархию. Однако, реализация такова, что чем меньше этих файлов, тем лучше, т.е. с точки зрения производительности нужны длинные файлы (а разрабатывать их неудобно, класс дробить нельзя). Да, конечно, взялся за ООП, прекращая думать об эффективности - ООП организует код, а не гарантирует какие-то другие преференции. Однако, PHP, это язык, который интенсивно используется в Web с одной стороны (много клиентов одновременно, большое потребление памяти и ресурсов) и крайне медленный сам по себе с другой. Все это не способствует развитию ООП в PHP, да и вообще PHP как языка крупных проектов, где ООП обычно и применяется. Если вам потребовался ООП и вы понимаете зачем, скорее всего у вас крупный проект. Если у вас крупный проект, зачем вы ориентируетесь на PHP? Сервера лишние? Или как Facebook хотите потом компилятор писать? Это понимают и другие разработчики, поэтому весь ООП код он либо заимствован из других языков (в которых решаются проблемы отсутствующие в PHP), либо написан людьми, которые сами не очень верят в необходимость ООП на PHP, либо которые не очень понимают ООП.

PS Да я согласен, PHP развивается, но фундаментальные недостатки никуда не деваются и чем больше проходит времени тем сложнее их исправить. Разработчикам же прикладного ПО проще сменить язык, чем изображать "хорошую мину" при "Но PHP я не люблю".

А теперь речь зашла о производительности... Мы точно скоро дойдём до религии --- не долго осталось.

Так вот: существуют решения (абсолютно прозрачные для PHP-программиста), как APC, xCache, etc. --- акселераторы, которые позволяют не парсить файлы каждый раз, а пользоваться готовым байт-кодом (фактически это компиляция как в Java, C#, etc.). Помимо прочего, в фреймворках типа Symfony существует автоматическая сборка классов в один большой файл --- вкупе с акселератором это заставляет забыть о надуманной проблеме производительности.

Проблема производительности появляется практически всегда на уровне работы с СУБД, вы же должны это знать. А константное значение, связанное с парсингом, всегда можно поправить.

P.S. Чисто FYI, к ООП это, ясное дело, ну никак не относится.