Comments 82
что значит на полную силу?
Я имел ввидк примерно следующее: знать и использовать PHP design patterns, везде использовать ссылки на объекты а не их самих; при создании нового файла в большинстве случаев писать class, а потом по ситуации :-)
везде использовать ссылки на объекты а не их самих
А как можно использовать одно или другое по выбору, если язык предоставляет только один вариант?
при создании нового файла в большинстве случаев писать class
Писать class везде где ни попадя, это не "использовать на полную силу", это маразм.
Использовать ООП, это не design patterns и class везде, это значит, мыслить объектами, а не раздельными процедурами и данными.
А как можно использовать одно или другое по выбору, если язык предоставляет только один вариант?
В PHP5, — к счастью да. В четверке, — программист мог решать это в объявлении функции.
Писать class везде где ни попадя, это не "использовать на полную силу", это маразм.
У меня там смайл стоит. Я и не говорил где ни попади.
мыслить объектами, а не раздельными процедурами и данными
согласен, но это, в том числе и знание design patterns, вы согласны?
В четверке, — программист мог решать это в объявлении функции.
Если вы о "&", то так и в 5-ке можно, но это не совсем то и не совсем так же работает.
это, в том числе и знание design patterns, вы согласны
Умение вырабатывать шаблон решения для распространенной проблемы, а так же быть в курсе тех, что были выработаны другими, вещь полезная, но не совсем уверен, что это относится к ООП. Хотя тоже на всякий случай поставлю смайл :)
use full force Luke!
Можно встречный вопрос - а присутствует ли полноценная реализация вех принципов ООП в РНР (с указанием версии), чтобы их можно было применять? Сам использую РНР и люблю его, но не назвал бы его "полностью правильным" объектно-ориентированным языком. Про PHP6 еще не слышал, спасибо за информацию, ушел искать.
А каких конкретно вещей из "полноценной" реализации вам не хватает в PHP5?
вот не знаю относится ли это к "полноценной" реализации (скорее не относится), но в OOP PHP5 мне не хватает Friend-классов. но в целом полностью устраивают возможности (еще бы более удобную работу со свойствами и вообще было-бы супер)
UFO just landed and posted this here
Namespaces уже в 5.3 будут, но это не совсем ООП.
Что вы подразумеваете под перегрузкой методов? Разные методы в зависимости от типа аргументов? В слоботипизированном PHP это реализуется, но в другой форме.
Что вы подразумеваете под перегрузкой методов? Разные методы в зависимости от типа аргументов? В слоботипизированном PHP это реализуется, но в другой форме.
может имелась ввиду перегрузка операторов?
UFO just landed and posted this here
Нет, через if (is_int(...) в теле функции :)
Приведите пример функции, где это требуется в PHP и как по-вашему в том же PHP это можно было бы реализовать "правильно".
Приведите пример функции, где это требуется в PHP и как по-вашему в том же PHP это можно было бы реализовать "правильно".
UFO just landed and posted this here
мечта блин... тоже хочу такую чтуку, хотя она частично в пятом есть, но только для указания классов которые нам нужны, к примеру __construct(MyClass $myclass) {}
Данная проблема для PHP не слишком большая, а решение весьма спорное.
большая, решение - отличное.
UFO just landed and posted this here
Может проблема и действительно не меньше, неправильно выразился. Решение спорно, как и большинство решений дословно, переносимые с других языков.
В текущей реализации PHP, это можно решить нисколько не сложнее:
Более того, если в методе подразумеваются другие действия, не зависящие от типа аргумента, то в вашем варианте их придется держать в двух местах.
В текущей реализации PHP, это можно решить нисколько не сложнее:
public function setLocale($locale)
{
if (is_object($locale)) {
$locale = $locale->getId();
}
$this->localeId = $locale;
}Более того, если в методе подразумеваются другие действия, не зависящие от типа аргумента, то в вашем варианте их придется держать в двух местах.
а если у нас не два, а 20 различных видов значений может быть? встолбик использовать if/elseif или начать уже писать switch?
UFO just landed and posted this here
А как мне узнать о том, что такой метод принимает только int и экземпляры только класса Locale
Да так же, как собственно и для любого метода, который может принимать только int. Документированием/самодокументированием кода.
Да, IDE для PHP менее развиты, чем IDE для некоторых других языков. Да и вряд ли они вообще в принципе могут иметь многие фишки которые есть в IDE сильнотипизированных языков.
Но это общая проблема, а не только перегрузки методов и тем более ООП.
Ну "три кита" (наследование, полиморфизм, инкапсуляция) присутствуют уже в РНР5, поэтому снимаю свой коммент. Т.е. я все-таки бы отнес РНР (начиная с 5) к объектно-ориентированным языкам. Все остальные особенности относятся к реализации.
Но шутка в том, что в РНР остается возможность писать и в старом добром процедурном стиле, и ничего этому не мешает. Что, наверное, и раздражает в РНР (наряду с нестрогой типизацией) тех, кто пишет на Java и .NET.
Но шутка в том, что в РНР остается возможность писать и в старом добром процедурном стиле, и ничего этому не мешает. Что, наверное, и раздражает в РНР (наряду с нестрогой типизацией) тех, кто пишет на Java и .NET.
Кто-нибудь мог бы подкинуть ссылок про то, КАК его использовать правильно. Желательно с примерами. Сейчас использую ООП только для разделения пространств имён логически отдельных кусков программы.
http://ru.wikipedia.org/wiki/Шаблоны_про… отсюда и дальше
Стремлюсь использовать в php "best practices" такие как паттерны, разработка посредством тестирования и т.д.
Но пока не хватает опыта в этих вещах.
Вобще предлагаю сформулировать список "лучших практик" на php, которые по вашему мнению нужно стараться использовать.
Но пока не хватает опыта в этих вещах.
Вобще предлагаю сформулировать список "лучших практик" на php, которые по вашему мнению нужно стараться использовать.
Он сформирован давно, очень много полезной инфы можно по этой теме (архитектура приложений, разработка, паттерны) найти по другим языкам - С, Ява.
Да, но его можно было бы скорректировать, учитывая особенности php.
Что-то стоит применять, от чего-то наверно лучше отказаться.
Что-то стоит применять, от чего-то наверно лучше отказаться.
Дело в том, что когда я начинал понимать все эти шаблоны, я тоже был ленив и думал, что они будут немного различаца применительно к пхп и вебу - задачи все таки разные. Но потом, когда опыта стало чуточку больше понял, что вообще-то они не привязанны веревкой ни к какому языку, а надо просто чуточку подняпряься, подумать, и самому понять (а это уже будет очевидно) как можно их использовать в вебе, когда ты пишешь на пхп :)
UFO just landed and posted this here
При всех возможных недостатках php - это не значит что там не нужно стремиться к хорошей архитектуре. Сложно опровергнуть, что php - самый популярный на данный момент в рунете.
И при всем уважении к другим языкам, для них и хостинг сложней найти и заказчика, который захочет.
Просто я также работаю с asp.net и даже под эту замечательную технологию трудно заказчиков убедить.
Я бы сказал так - везде хотят php.
И при всем уважении к другим языкам, для них и хостинг сложней найти и заказчика, который захочет.
Просто я также работаю с asp.net и даже под эту замечательную технологию трудно заказчиков убедить.
Я бы сказал так - везде хотят php.
UFO just landed and posted this here
Ну в автомобольной промышленности щас не понятно кто прибыльней - такое ощущение, что многие автогиганты известные в кризисе, а китайские и корейские машины хорошо продаются.
Поэтому вполне вероятно, что производить дешевые вещи может оказаться выгодней для производителя.
Соотв. предлагая услуги на php вероятность найти заказчика (особенно удаленно) намного выше, чема на RoR или Java.
Поэтому вполне вероятно, что производить дешевые вещи может оказаться выгодней для производителя.
Соотв. предлагая услуги на php вероятность найти заказчика (особенно удаленно) намного выше, чема на RoR или Java.
То что надо научится мыслить объектно - это правильно, но вот говорить о том, что PHP - это совсем не тот язык, в котором можно реализовыавть свои мысли объектно - полностью не согласен
лучше всего ООП показывает себя в программах, которые потенциально могут работать достаточно продолжительное время, а не в скриптах...
по крайне мере у меня такое имхо
по крайне мере у меня такое имхо
а область применения пхп сильно ограничевает его использование для написания не-скриптов, хотя, конечно и не запрещает...
Мне кажется что называть бизнес логику работы сайта "скриптом" - немножко неправильно
возможно. Но здесь я больше вкладываю в понятие скрипта не сложность, а процесс его выполнения. Если нечто крутится в памяти, составные части которого взаимодействуют друг с другом, совершая в течение некоторого времени, определенные действия, то с ООП в такой ситуации развернуться можно будет полнее, нежели когда это нечто должно отработать один раз(и еще раз и еще много-много раз) и выдать результат в зависимости от входных данных, после чего благополучно завершиться до следующего запуска.
А в чем разница?
Просто жизненный цикл страницы начинается и заканчивается быстро.
Просто жизненный цикл страницы начинается и заканчивается быстро.
нечто крутится в памяти, составные части которого взаимодействуют друг с другом, совершая в течение некоторого времени, определенные действия
А в веб-сценариях это разве не так?
Разве программа, которая на основании полученных данных формирует ответ, чем-то принципиально отличается от других?
PHP-сценарий быстро выполняется... Для кого быстро? Он выполняется на протяжении миллиардов процессорных тактов.
он выполняется настолько быстро, что в процессе выполнения не может появится никаких новых входных данных.
То есть вы имеете в виду, то что php-сценарий не интерактивный? Но ни время выполнения, ни ООП тут не причем.
позволю себе вклиниться в ваш разговор...
состояние объекта в пхп (осбственно как и сам объект) храниться на протяжении выполнения сценария, а не на протяжении работы всего приложения в целом, как это может быть например в Java...
здесь нужно понимать следующее, если речь идёт о разработке веб-сценариев (пускай обычных сайтов), то того ООП, который присутствует в ПХП _может_ быть вполне достаточно (именно может, так-как могут быт разной сложности задачи даже для обычных сайтов), другое дело если речь идёт о разработке действительно архитектурно-сложного приложения, где _правильное_ применение объектного дизайна действительно является важной состовляющей всей системы и где возможные допущенные ошибки на стадии проектирования могут повлиять на систему в целом.
состояние объекта в пхп (осбственно как и сам объект) храниться на протяжении выполнения сценария, а не на протяжении работы всего приложения в целом, как это может быть например в Java...
здесь нужно понимать следующее, если речь идёт о разработке веб-сценариев (пускай обычных сайтов), то того ООП, который присутствует в ПХП _может_ быть вполне достаточно (именно может, так-как могут быт разной сложности задачи даже для обычных сайтов), другое дело если речь идёт о разработке действительно архитектурно-сложного приложения, где _правильное_ применение объектного дизайна действительно является важной состовляющей всей системы и где возможные допущенные ошибки на стадии проектирования могут повлиять на систему в целом.
Аргументируйте своё мнение.
Господин Chapaev, я разделяю ваши симпатии к Ruby. Отчасти и к Java. Но у меня впринципе не стоит вопрос "на чём программировать", "какой язык лучше" и т.п. И не считаю, что php лучше какого-то языка. Я не говорю, что ООП в php6 будет сравним с ООП да хотя бы в том же Ruby. Я вообще не собираюсь поднимать эти вопрос. Потому что знаю на них ответы.
Мне просто интересно кто как использует ООП в PHP и всё.
Мне просто интересно кто как использует ООП в PHP и всё.
мне сильно трудно придумать, куда можно воткнуть ООП в ПХП, чтобы оно выглядело красиво. Не того уровня задачи.
Вы либо не в полной мере знаете уровень задач на ПХП. Либо не знаете уровень для ООП.
Я думаю одним из примеров нужного использования ООП в php может являться след. решение: уровень доступа к данным сделать через астрактный класс, от которого будет наследоваться "провайдер" для конкретной СУБД. И соотв. для смены СУБД потребуется просто переписать провайдер, а остальные уровни системы даже не заметять подмены СУБД.
Давайте поподробнее взглянем на ваш пример. Очень распространенное мнение, что смена реализации класса доступа к БД достаточно для смены самой БД. Вы в это верите? Я еще не сталкивался с ситуацией, когда необходимо сменить БД в проекте, без глубокого переписывания самого проекта. В данном случае класс просто меняет обращение к БД с функций на методы. Кроме того мы получаем дополнительные вызовы, которых можно легко избежать. Так что пример с БД не самый хороший.
Мне кажется что красивое решение.
Эту идею я почерпнул из хорошей книги по asp.net.
Имеется ввиду, что унаследованный класс от абстрактного будет абсолютно по разному реализован с учетом особенностей СУБД. А если на бизнес-уровень передаются коллекции объектов от дата-уровня, то какая разница как они реализованы на дата-уровне - там к чему-угодно может быть обращение и к СУБД и xml и текстовый файл, а может даже web-сервис.
А дополнительные вызовы сокращать кэшированием.
Эту идею я почерпнул из хорошей книги по asp.net.
Имеется ввиду, что унаследованный класс от абстрактного будет абсолютно по разному реализован с учетом особенностей СУБД. А если на бизнес-уровень передаются коллекции объектов от дата-уровня, то какая разница как они реализованы на дата-уровне - там к чему-угодно может быть обращение и к СУБД и xml и текстовый файл, а может даже web-сервис.
А дополнительные вызовы сокращать кэшированием.
Тогда мне кажется вы не писали больших приложений :)
А что не так с данной теорией?
Может меня не правильно поняли? Я имею ввиду не универсальные запросы к БД, а именно написание провайдеров с учетом особенностей каждой СУБД.
А на бизнес-уровень передавать коллекции объектов от дата-уровня.
Разве большое приложение не может иметь такую архитектуру, где все разделено на уровни(BBL, DAL, UI) и можно переделать один, не меняя остальные?
Может меня не правильно поняли? Я имею ввиду не универсальные запросы к БД, а именно написание провайдеров с учетом особенностей каждой СУБД.
А на бизнес-уровень передавать коллекции объектов от дата-уровня.
Разве большое приложение не может иметь такую архитектуру, где все разделено на уровни(BBL, DAL, UI) и можно переделать один, не меняя остальные?
может быть это к коменту выше :) ?
это был коммент мне.
На практике я не видел ни одного удачного решения подобной системы, которая может адекватно использовать различные базы данных на уровне сильно большем, нежели "получить строчку по айдишнику отсюда, получить строчку по йдишнику оттуда, записать строчку по айдишнику туда".
Хотя уровни, это несомненно хорошо.
На практике я не видел ни одного удачного решения подобной системы, которая может адекватно использовать различные базы данных на уровне сильно большем, нежели "получить строчку по айдишнику отсюда, получить строчку по йдишнику оттуда, записать строчку по айдишнику туда".
Хотя уровни, это несомненно хорошо.
на пхп? :) нет :)
Зависит от задач на самом деле. В каких то проектах использую в полную силу, где то не использую абсолютно.
что значит не устраивать holy war?
Ведь в посте есть слово PHP, а значит холиворам быть! :)
по теме:
года 4 назад назад, я писал проект на php и там ООП использовался, но его реализация в php на тот момент была, скажем так, убогой. Но, тем не менее ООП использовали и будем использовать (благо сейчас языков много - есть из чего выбрать)
Ведь в посте есть слово PHP, а значит холиворам быть! :)
по теме:
года 4 назад назад, я писал проект на php и там ООП использовался, но его реализация в php на тот момент была, скажем так, убогой. Но, тем не менее ООП использовали и будем использовать (благо сейчас языков много - есть из чего выбрать)
Т.к. уже отхабрили, а значит вопрос этот к войне не приведет, то задам (просто интересно):
и на чём пишите сейчас?
и на чём пишите сейчас?
ruby и perl(просто для души :)
на самом деле я ничего не имею против php, просто на мой взгляд есть более интересные языки. Те-же самые ruby и python, например
на самом деле я ничего не имею против php, просто на мой взгляд есть более интересные языки. Те-же самые ruby и python, например
Я правильно понимаю, что среди людей на хабре только один человек из пяти не является разработчиком на ПХП?
Sign up to leave a comment.
Вы используете ООП на полную силу в PHP?