- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
ООП используется для крупных проектов, для которых важны управляемость проектом, относительная лёгкость разбора в коде. В целом для крупных проектов при правильном подходе в использовании ООП можно добиться существенного уменьшения сроков разработки.
Все зависит от самих проектов и кто их делает. Тот же Битрикс использует в основном функциональный стиль программирования. Друпал тоже на функциях весь написан. Обе CMS, к слову, довольно тяжелые.
Если вести речь о небольших проектах, то там можно вполне нормально использовать ООП. Особых затруднений это не вызывает. Чтобы не изобретать велосипед, можно использовать схему "один класс - один файл", написать нормальный автозагрузчик и забыть о include/require. Пиши код в свое удовольствие.
Для себя я вывел одно - высоконагруженным проектам ООП противопоказано.
Почему? Если верить профайлерам, то существенной разницы нет. Как показывает практика, основным бутылочным горлышком на нагруженных проектах становится база данных и жесткие диски.
Значит вы просто не умеете планировать структуру проекта, если у вас объекты создают нагрузку.
Уже в нескольких топиках на этом форуме заметил, что многие советуют использовать ООП только в крупных проектах. Хочу спросить у этих людей: как вы пишете модульные тесты (если пишете) для процедурного кода?
Пример: есть класс User. У него есть методы save() и delete(), которые соответственно сохраняют и удаляют пользователя из некоего хранилища. Протестировать этот класс легко. Достаточно передать ему при создании вместо объекта хранилища заглушку и проверить вызовы методов этой заглушки.
Если же у нас вместо класса User будут функции user_save() и user_delete(), то придется каждый раз передавать в аргументах эту заглушку. Или вы как-то по-другому делаете?
n0name, скорее-всего будут использовать зло-global )
друпалисты это объясняют тем, что когда создавалось ядро и его концепция как таковая, ООП в ПХП был достаточно слабо развит, если вообще был (это 2001 год кажется, не помню, уже тогда было PHP 3 или нет... в то время мы все по Пёрлу тащились), и никакой поправки на "нагруженность" в пользу процедурного, там точно небыло. А когда проект начинает развиваться, обрастая коммунити, то никто архитектуру ядра полностью менять не станет, точно такая же ситуация и с процедурным WordPress например. Однако, сейчас, достаточное кол-во модулей, которые усиленно юзают ООП (например хоть те же Views, CTools и т.д.)
по сабжу: ТС, если вы не смогли понять принципы OOP&D по тем книгам, которые читали - читайте другие, это достаточно обширная тема, что бы вам могли понятно вот просто так объяснить зачем они нужны... это нужно прочувствовать.
Одно можно сказать с полной уверенностью: не начав изучать ООП проникнуться прелестью такого программирования не возможно. Все абстрактные объяснения про рабочих и бригадиров у меня лично в голове рисуют рабочего и бригадира. Начните писать, почитайте Мэтт Зандра, не найдете - скиньте мне в личку вашу почту - отправлю вам в .djvu
Есть множество полезной литературы в сети, но лучший способ учить - практиковаться.
Странный вопрос, но я его не один раз слыхал от ПШП-ов. Для меня он всегда звучал странно, потому как много в то время писал на java, которая полностью построена на ООП, и без классов там даже "Hello world!" не напишешь.
ООП - это не для крупных или мелких проектов, или для какого нибудь языка, это концепция, стиль, философия, которая стоит на трех китах: инкапсуляция, наследование и полиморфизм. Пока вы не осознаете, что это, зачем, и с чем его едят, этот разговор вообще не имеет никакого смысла.
При этом ПШП уже пытается освоить следующий уровень - концептуальное программирование.
> если Вы не видите смысл в использовании классов в РНР, не используйте их
> Используйте процедурный подход, т.е. функции
Плохой совет.
Я бы посоветовал посмотреть любой PHP-фреймворк. Для учебных целей лучше всего подойдет CodeIgniter 1.0 (самый простой и лучше всего документированный) или YII (чуть посложнее, но зато побольше встроенных компонент)
Сделайте простенький блог или статейный движок с админкой и на голом php и на фреймворке. Оценить скорость разработки, возможности по наращиванию функционала и внесению каких-нибудь изменений.
Мне кажется после этого должно все встать на свои места.
Если поймете в чем разница, сэкономите кучу времени и сил.
Всем привет! Никак не могу понять, какой смысл от использования классов в php. Для каких целей они нужны я не понял даже прочитав книгу для чайников... Насколько я смог все это понять, что класс содержит в себе переменные + функции для работы с ними. Что по моему сложнее, так как приходится создавать новый объект класса, и т.д. Объясните ламеру что к чему, а самое главное смысл. Спасибо!
На самом деле с таким вопросом сталкивается каждый, кто начинает программировать и "перерастает" функциональное программирование.
Разница объектного программирования с функциональным заключается в том что объекты, в отличие от функций, могут обладать свойствами. И с этими свойствами можно работать внутри объекта, обращаясь к ним через $this->attribute. Поверьте, это очень удобно.
Если вы работаете с функциями, то эти атрибуты вам придется передавать в каждую функцию по-отдельности, чтобы работать с ними.
Говоря "круче" ООП - это подход, имеющий 3 свои ключевые особенности: полиморфизм, наследование и инкапсуляцию. Почитайте про каждую из них и станет легче :)
Ни о чем таком в функциях не может быть и речи ;)
Для учебных целей лучше всего подойдет CodeIgniter 1.0 (самый простой и лучше всего документированный) или YII (чуть посложнее, но зато побольше встроенных компонент)
С небольшим уточненим - Yii более "оопешнее", он более предпочтителен, но CodeIgniter более понятен для новичков - хотя и местами приучает к вредным вещам.
Kohana 3.1 - золотая середина )
а кохана + библиотеки Зенда = вполне вменяемая замена Yii
личное имхо, но решил отказаться от Yii в пользу кохана+что-то ещё (для небольших проектов, с простенькой админкой) и Zend для всего остального.
Кохана правда ужасно документирована, но если отсылаете к изучению исходников, то Ко - самое то, с чего можно начать