ООП: да или нет? [PHP + MySQL]

Здравствуйте

Предлогаю в этой теме обсуждать ООП в PHP, ну и MySQL кудато...

Я программист, если можно так сказать, НАЧИНАЮЩИЙ, в основном работал с процедурным кодом а сейчас решил сделать как-бы
свою маленкую CMS, скорей даже не CMS а несколько отдельных модулей, не зависящех друг от друга, с собствеными конфигами,
и отлично работающими вместе, чтоб не писать постоянно одно и тоже для каждого проекта.

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

Просьба: Если чтото обьясняете то прилепите код для макс. понятности.

Я начну...
Зачем исполизовать private, public, protected свойства и методы если с static тоже отлично работает + на мой взгляд читаемость кода выше?

По вашему вопросу. Читаемость на порядок ниже как раз. Когда вы видите определение private вы сразу понимаете, что этот метод будет использовать только здесь. Многие студии (Zend Studio и другие) формируют список быстрых методов на основе этих определений.

По поводу ООП. Чем крупномасштабнее приложение, тем вы больше будете запутываться в процедурном стиле. Меленькие приложения наоборот выгодно делать процедурным стилем, т.к. это избавляет от ненужных определений и повышает эффективность кода.

А причем тут MySQL?

Книга М. В. Кузнецов и И. В. Симдянов "Объектно-ориентированное программирование на PHP" 2007 + CD - price 290 rub.

VeMax, Ну мало ли кто захочет показать как строить правельно класс для управления базами
к примеру в коде гдето прописал Data::select("table", "fileds", "conditions"; и сразу получил весь список,
а не пишеш как мин 5 строк кода...

Нынче PHP както сильно с MySQL связан

Цитата ("egoistu"):

... ну и MySQL кудато...

Аааааааааааааааа

Цитата ("sergannd_snz"):

Книга М. В. Кузнецов и И. В. Симдянов "Объектно-ориентированное программирование на PHP" 2007 + CD - price 290 rub.

А ты сам по этой книжке учил?

egoistu,
Скачай в нете книгу по ООП (автор Гради Буч).
Да, все верно тебе сказали. Чем больше приложение, тем сложнее в нем использовать процедурное проектирование.
При !грамотном! использовании ОО подхода в проектировании ПО, разработка становится приятным удовольствием. =)

Зачем использовать private, public, protected? Представь себе контору, где 50 программистов сидит. И все работают над одним проектом.
И если ты не будешь использовать для своего маленького модуля private, все кому ни лень, будут лезть в твой код из своих модулей.

Сокрытие данных
Сокрытие данных — неотделимая часть ООП, управляющая областями видимости. Является логическим продолжением инкапсуляции. Целью сокрытия является невозможность для пользователя узнать или испортить внутреннее состояние объекта.

Что касается MySQL - это просто для работы с БД, он используется одинаково и в процедурных, и в ООП-приложениях, и вообще вне стороннего кода...

Цитата ("egoistu"):

Зачем исполизовать private, public, protected свойства и методы если с static тоже отлично работает + на мой взгляд читаемость кода выше?

Судя по вашему вопросу вы не совсем понимаете суть ООП.

Я бы порекомендовал вам отойти от практики ООП программирования(тем более в php, так как здесь сама модель еще хромает) и понять его суть. Не зря во всех книжках и тд пишут что нужно ассоциировать обьекты и классы с естесственным миром.
Лучше всего если время и деньги послушать курс лекций в каком-нибудь хорошем университете ну или реально поучиться у гуру в этом вопросе.
Если без этого то сначала прочитайте книги по общему пониманию ООП и проектированию(Фаулер, Скотт может быть еще кто-то).

Цитата ("intelit63"):

Цитата (egoistu):
Зачем исполизовать private, public, protected свойства и методы если с static тоже отлично работает + на мой взгляд читаемость кода выше?

Судя по вашему вопросу вы не совсем понимаете суть ООП.

Интересно - сколько еще человек не уловили иронии?

Прошу прощение за отсутствие (тех. проблеммы)
прочел Ваши посты и очень благодарен за них

Цитата ("sergannd_snz"):

Книга М. В. Кузнецов и И. В. Симдянов "Объектно-ориентированное программирование на PHP" 2007 + CD - price 290 rub.

нашел, читаю...


Цитата ("MaratCrash"):

egoistu,
Скачай в нете книгу по ООП (автор Гради Буч).
Да, все верно тебе сказали. Чем больше приложение, тем сложнее в нем использовать процедурное проектирование.
При !грамотном! использовании ОО подхода в проектировании ПО, разработка становится приятным удовольствием. =)

обязательно гляну, но по очереди
думаю, те и эти знания не будут конфликтовать

(слежу за постами...)

Цитата ("egoistu"):

Хотелось бы узнать более подробно про плюсы и минусы ООП от спецов работаюших с этим ежедневно.

Когда пишешь класс для раздела на сайте, а потом от него наследуешь класс для аналогичного админского раздела, то часто очень приятным способом
админский раздел начинает работать сразу, без особых изменений.

Как бы пишутся 2 раздела за 1 раз.

ДА ООП

ООП КРАЙНЕ облегчает процесс программирования. Не просто в разы а в десятки или даже сотни раз, особенно на сложных проектах. По этому только ДА.
Справедливости ради надо добавить, что в принципе ООП в некоторых задачах бывает гораздо менее производителен чем "структурно-процедурное программирование", но если Вы пишете на Пхп - значит скорость выполнения скриптов и нагрузка на сервер - это последнее, о чем Вы задумываетесь. Да, ООП.

Цитата ("dervinar"):

если Вы пишете на Пхп - значит скорость выполнения скриптов и нагрузка на сервер - это последнее, о чем Вы задумываетесь

Вам еще не надоело писать этот бред? Это риторический вопрос, отвечать не надо

filipchuk,
А у вас есть аргументированные возражения против этого "бреда"? С удовольствием их прочитаем.

Множество Hiload-проектов, написанных на PHP - подойдет в качестве аргумента?

Вы располагаете сведениями об эффективности их работы? И о затратах на серверное оборудование? Вы можете привести статистику и показать, что затраты на серверное оборудование немногим более затрат на оборудование для аналогичного проекта, написанного на Perl, Python не говоря уже о C#, Java и D. Причем желательно привести в пример зарубежные проекты. Ибо наши заказчики пока не умеют считать деньги и надеются сэкономить на разработке, от чего потом несут убытки.

За примера обращайтесь в Гугл, успешные проекты на ПХП не такая уж и тайна
По поводу статистики - я думаю, она доступна инвесторам/архитекторам/прожект_менеджерам (или людям, определяющим платформу разработки для будущего проекта), к таковым людям я не отношусь к сожалению
Насчет наших заказчиков - всех под одну гребенку не стоит, но в целом Вы правы