для подавляющего большинства операций, производимых CMS и аналогичными web-based системами, она не нужна. а вот когда нужно, тогда да - ООП.
Я ж не сказал, что вообще никогда не нужно его использовать. В большинстве случаев можно и нужно обойтись без него.
Вообщем-то я в том числе говорил и про людей, которые относятся к проекту как к своему детищу.
Мотивация - это не только заработная плата. Но если заработная плата низкая, то как бы человек не относился к проекту, он скорее всего уйдет из компании или будет халтурить, ибо нужно успеть где-то еще что-то ухватить, чтобы жить нормально... или хотя бы интересно... а если не выходит, то почему бы не доделать другое свое детище, которое более совершенно и перспективно, чем обычный корпоративный сайт или клон вконтакте.
Суть простая - или заработать, чтобы нормально жить, или выбирать лучшее из имеющегося. В случае, если денег мало, остается второй вариант: есть два детища: одно - сайт кого-то там (пусть красивый, с прикольными фишечками и т.д.) и еще некий проект, который все же проработан данным сотрудником полностью без вмешательства третьих лиц (типа менеджера). Что ему будет ближе и чем ему будет хотеться заниматься больше? ИМХО собственным проектом. Ведь он может быть помимо прочего еще и перспективнее в техническом смысле (а может быть и в финансовом, тем более что тогда разработчик будет и собственником этого проекта). Хотя он и воспринимает оба проекта своими детьми.
Может, путано как-то изъясняюсь. Надеюсь, поняли смысл.
Насчет роста системы и расширяемости, на мой взгляд это недостаток архитектуры большинства неООП систем - ООП тут не причем. неООП системы разрабатывались по большей части когда-то давно. Затем все ринулись использовать везде где нужно и не нужно ООП. Начали прорабатывать более расширяемые системы, но уже проектировали их с ипользованием ООП. А про функциональный подход все забыли, потому что в нюансах не разбирались, или просто на моду повелись или по каким-либо еще причинам.
Экономия на спичках - вопрос спорный. В ряде случаев, в небольших проектах - да. В крупных и сложных - совсем нет.
Если у вас простой корпоративный сайт с небольшим кол-вом функций и небольшой посещаемостью, конечно, такая оптимизация чего-либо значительного не даст.
Но если взять крупный портал или сложную систему (например, очень развитую CRM), то такой подход может в итоге помочь. Пусть не так сильно, как оптимизация запросов к БД, но (я считаю, что оптимизируем не только работу с БД) все же даст прирост производительности.
Как я выше писал, для вызова одного метода грубо говоря совершается в два раза больше операций. Каждая требует времени и памяти. В случае простой системы из двух-трех независимых объектов или с крайне неглубокой иерархией классов и объектов нет смысла заморачиваться на этот счет.
Но крупный портал/CRM может содержать десятки классов, сотни объектов, каждый из которых в свою очередь содержит еще десятки объектов. Представьте, сколько в этом случае переходов с одного адреса памяти на другой потребуется в ряде случаев даже для вызова одного метода. А учитывая, сколько раз происходят подобные вызовы и сколько конструкторов мы запускаем, сколько объектов храним в памяти? Прилично выходит в итоге-то.
Мне как-то повезло сравнить в производительности две CMS средней величины. Одна написана на ООП. Вторая - чисто функциональный подход. Набор функций один в один. Обе системы достаточно качественно написаны. Но разница в производительности в реальных условиях оказалась вполне достаточной, чтобы отказаться от системы с ООП.
Если реального специалиста не мотивировать, то и он либо не особо будет стараться (стараться и делать все на пять будет в свободную минутку в собственных проектах, которые делает для знакомых или просто из интереса) в ваших проектах, а потом, когда ему надоест все это, уйдет туда, где ему и платить будут приличнее и мотивировать будут лучше. Хорошему спецу место всегда найдется.
кстати говоря, в данном примере вообще пофигу использовали ли мы классы только как контейнеры для функций или использовали больше возможностей. одна строка, которая вполне может находится внутри метода класса, который выполняет действия над самим объектом этого класса.
Это попытка показать, что нет каких-то особенных различий в удобочитаемости ООП кода и неООП кода. Плюс, что делает машина при том или ином подходе.
в вебе так часто получается, особенно если работа идет над какой-то CMS средней сложности... хотя возможно пример действительно не очень вышел. Но, я надеюсь, идея понятна
1. хорошо оформленный функциональный код может быть не менее удобочитаемым, чем ООП. А плохо оформленный ООП код может быть точно таким же нечитаемым, как плохой функциональный. Пример:
можно написать некоторую систему на ООП. Допустим у нас есть класс для обработки и вывода информации о людях.
ООП: $man->getHTML();
функциональный код: manGetHTML или getHTMLForMan() или как угодно иначе обзовите функцию. Разница - в отсутствии символа ->, но его и заменить можно чем-то если вам удобнее с разделителями.
На уровне машины:
функциональное программирование: найдем адрес функции, запомним место, на котором выполняется вызов функции, перейдем по адресу функции, выполним ее код, вернем результат куда нужно и продолжим выполнение программы.
ООП: обработаем класс и запишем его в память, создадим объект класса и запишем в память, при вызове метода объекта найдем адрес объекта, запомним откуда мы уходим в класс, найдем в классе адрес функции.....
Со многими пунктами не согласен.
В частности, пока есть что оптимизировать и что даст после оптимизации значительный прирост производительности - нужно оптимизировать. И только потом прибегать к кешированию. Ибо кеширование - не всегда хорошо (например, данные могут обновляться так часто, что кеш будет перестраиваться не реже или ненамного реже, чем загрузка страницы с этими данными - смысл тогда в кеше?), а реализовать его иногда бывает сложнее, чем оптимизировать несколько участков кода. Поэтому правильный путь нужно выбирать по ситуации, а не сразу кидаться кешировать все и вся.
ну насчет персистентных коннектов к базе можно поспорить.
Во-первых, они работают только когда PHP установлен как модуль Apache, что не всегда хорошо.
Во-вторых, чтобы нативно работать с MySQL 4.1 и новее без использования старых методов авторизации и устаревших функций, нужно использовать MySQLi расширение/функции. Они не поддерживают постоянные соединения, увы. Как и интерфейсы ко многим другим СУБД. Поэтому вся оптимизация работы с БД идет через правильные и оптимизированные запросы и уменьшение их количества.
Насчет акселераторов - согласен.
В зависимости от того, какой макет сделал дезигнер, либо оставляю как у :link, либо отличный от него. Но за последние фиг знает сколько лет ни разу не совпадал он со стандартными цветами
Да и не зря же на сайте денвера красуется (красовалась не так давно?) надпись, что этот пакет хорош для тестового сервера, а не как реальный веб-сервер, и того же мнения придерживается большинство проф. разработчиков (а некоторые вообще считают его злом, которое надо искоренять)
Во-первых поставить все поотдельности занимает не так много времени. Во вторых, устанавливая все отдельно, знаешь где какие конфиги и как что настроено, легко все переконфигурировать. В денвере это сложнее.
Простой пример - файлы виртуальных хостов переписываются при каждом старте денвера.
PHP во второй версии денвера был крайне ограничен в плане расширений (в базе их не было вообще, дополнительные были не все, а следовательно, чуть сложнее проект - лезем и качаем их, а потом точно также конфигурируем)
Денвер хорош для разработки небольших сайтов. Но для сложных задач... Ну нет... Конфиги надо оптимизировать, расширения php докачивать и устанавливать, mysql переконфигурировать в большей степени, чем после стандартной установки.
Да и файлы разбросаны по каталогам порой не совсем понятно (например, php.exe находится в двух-трех каталогах)
Идея не нова, что-то подобное реализовывалось в WinFS, как писали выше. В любом случае. Мысль есть, а это хорошо.
Но есть такой момент.
Допустим, на нашем компьютере все отлично, программы ищут файлы по внутренним идентификаторам aka id auto_increment, допустим. Мы можем их перемещать по мнимому (для ОС) дереву каталогов. Все будет отлично работать.
Но если мы попытаемся перенести файл на другой компьютер? Как мы будем сохранять идентификатор файла? Как мы добьемся его уникальности на обоих машинах без повторной генерации?
Ну и от меня:
- Photoshop CS3 для верстки (нарезки макетов, подготовки графики где требуется)
- Dreamweaver CS3 для написания HTML-кода, CSS и даже PHP (вообщем-то использую только как блокнот с хорошей подстветкой синтаксиса и небольшими подсказками)
- Apache 2 стоит отдельно
- PHP стоит модулем к Apache (хотя у модульной связки и есть некоторые минусы, но на локальной машине большего не надо)
- MySQL стоит отдельно
(денвер не очень люблю)
- EMS MySQL Manager для работы с MySQL
- phpMyAdmin - там, где глючит EMS c кодировками (иногда тоже бывает, то ли из-за неправильной настройки кодировок сервера MySQL, то ли еще из-за чего)
- FireFox 2 + FireBug + WebDeveloper
- Internet Explorer
- Safari
- Windows'овские Notepad и WordPad
- SmartFTP для загрузки файлов на серверы
- документации по PHP и MySQL в HTML-формате
Хммм... Не наблюдал ни разу, хотя пользуюсь им уже довольно долго. По крайней мере когда резал макеты сайтов все было ок (а ресайзить и обрезать картинки по краям приходилось немало)
Я ж не сказал, что вообще никогда не нужно его использовать. В большинстве случаев можно и нужно обойтись без него.
Мотивация - это не только заработная плата. Но если заработная плата низкая, то как бы человек не относился к проекту, он скорее всего уйдет из компании или будет халтурить, ибо нужно успеть где-то еще что-то ухватить, чтобы жить нормально... или хотя бы интересно... а если не выходит, то почему бы не доделать другое свое детище, которое более совершенно и перспективно, чем обычный корпоративный сайт или клон вконтакте.
Суть простая - или заработать, чтобы нормально жить, или выбирать лучшее из имеющегося. В случае, если денег мало, остается второй вариант: есть два детища: одно - сайт кого-то там (пусть красивый, с прикольными фишечками и т.д.) и еще некий проект, который все же проработан данным сотрудником полностью без вмешательства третьих лиц (типа менеджера). Что ему будет ближе и чем ему будет хотеться заниматься больше? ИМХО собственным проектом. Ведь он может быть помимо прочего еще и перспективнее в техническом смысле (а может быть и в финансовом, тем более что тогда разработчик будет и собственником этого проекта). Хотя он и воспринимает оба проекта своими детьми.
Может, путано как-то изъясняюсь. Надеюсь, поняли смысл.
Если у вас простой корпоративный сайт с небольшим кол-вом функций и небольшой посещаемостью, конечно, такая оптимизация чего-либо значительного не даст.
Но если взять крупный портал или сложную систему (например, очень развитую CRM), то такой подход может в итоге помочь. Пусть не так сильно, как оптимизация запросов к БД, но (я считаю, что оптимизируем не только работу с БД) все же даст прирост производительности.
Как я выше писал, для вызова одного метода грубо говоря совершается в два раза больше операций. Каждая требует времени и памяти. В случае простой системы из двух-трех независимых объектов или с крайне неглубокой иерархией классов и объектов нет смысла заморачиваться на этот счет.
Но крупный портал/CRM может содержать десятки классов, сотни объектов, каждый из которых в свою очередь содержит еще десятки объектов. Представьте, сколько в этом случае переходов с одного адреса памяти на другой потребуется в ряде случаев даже для вызова одного метода. А учитывая, сколько раз происходят подобные вызовы и сколько конструкторов мы запускаем, сколько объектов храним в памяти? Прилично выходит в итоге-то.
Мне как-то повезло сравнить в производительности две CMS средней величины. Одна написана на ООП. Вторая - чисто функциональный подход. Набор функций один в один. Обе системы достаточно качественно написаны. Но разница в производительности в реальных условиях оказалась вполне достаточной, чтобы отказаться от системы с ООП.
Это попытка показать, что нет каких-то особенных различий в удобочитаемости ООП кода и неООП кода. Плюс, что делает машина при том или ином подходе.
можно написать некоторую систему на ООП. Допустим у нас есть класс для обработки и вывода информации о людях.
ООП: $man->getHTML();
функциональный код: manGetHTML или getHTMLForMan() или как угодно иначе обзовите функцию. Разница - в отсутствии символа ->, но его и заменить можно чем-то если вам удобнее с разделителями.
На уровне машины:
функциональное программирование: найдем адрес функции, запомним место, на котором выполняется вызов функции, перейдем по адресу функции, выполним ее код, вернем результат куда нужно и продолжим выполнение программы.
ООП: обработаем класс и запишем его в память, создадим объект класса и запишем в память, при вызове метода объекта найдем адрес объекта, запомним откуда мы уходим в класс, найдем в классе адрес функции.....
В частности, пока есть что оптимизировать и что даст после оптимизации значительный прирост производительности - нужно оптимизировать. И только потом прибегать к кешированию. Ибо кеширование - не всегда хорошо (например, данные могут обновляться так часто, что кеш будет перестраиваться не реже или ненамного реже, чем загрузка страницы с этими данными - смысл тогда в кеше?), а реализовать его иногда бывает сложнее, чем оптимизировать несколько участков кода. Поэтому правильный путь нужно выбирать по ситуации, а не сразу кидаться кешировать все и вся.
Во-первых, они работают только когда PHP установлен как модуль Apache, что не всегда хорошо.
Во-вторых, чтобы нативно работать с MySQL 4.1 и новее без использования старых методов авторизации и устаревших функций, нужно использовать MySQLi расширение/функции. Они не поддерживают постоянные соединения, увы. Как и интерфейсы ко многим другим СУБД. Поэтому вся оптимизация работы с БД идет через правильные и оптимизированные запросы и уменьшение их количества.
Насчет акселераторов - согласен.
Простой пример - файлы виртуальных хостов переписываются при каждом старте денвера.
PHP во второй версии денвера был крайне ограничен в плане расширений (в базе их не было вообще, дополнительные были не все, а следовательно, чуть сложнее проект - лезем и качаем их, а потом точно также конфигурируем)
Денвер хорош для разработки небольших сайтов. Но для сложных задач... Ну нет... Конфиги надо оптимизировать, расширения php докачивать и устанавливать, mysql переконфигурировать в большей степени, чем после стандартной установки.
Да и файлы разбросаны по каталогам порой не совсем понятно (например, php.exe находится в двух-трех каталогах)
Но есть такой момент.
Допустим, на нашем компьютере все отлично, программы ищут файлы по внутренним идентификаторам aka id auto_increment, допустим. Мы можем их перемещать по мнимому (для ОС) дереву каталогов. Все будет отлично работать.
Но если мы попытаемся перенести файл на другой компьютер? Как мы будем сохранять идентификатор файла? Как мы добьемся его уникальности на обоих машинах без повторной генерации?
- Photoshop CS3 для верстки (нарезки макетов, подготовки графики где требуется)
- Dreamweaver CS3 для написания HTML-кода, CSS и даже PHP (вообщем-то использую только как блокнот с хорошей подстветкой синтаксиса и небольшими подсказками)
- Apache 2 стоит отдельно
- PHP стоит модулем к Apache (хотя у модульной связки и есть некоторые минусы, но на локальной машине большего не надо)
- MySQL стоит отдельно
(денвер не очень люблю)
- EMS MySQL Manager для работы с MySQL
- phpMyAdmin - там, где глючит EMS c кодировками (иногда тоже бывает, то ли из-за неправильной настройки кодировок сервера MySQL, то ли еще из-за чего)
- FireFox 2 + FireBug + WebDeveloper
- Internet Explorer
- Safari
- Windows'овские Notepad и WordPad
- SmartFTP для загрузки файлов на серверы
- документации по PHP и MySQL в HTML-формате