[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: ООП, серебряная ли пуля?
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
casper - gg
Цитата (Wind @ 4.03.2016 - 23:01)
Ну это понятно, но для этого надо время, пока увы...


время это и есть один из атрибутов эксперта. Без того пока вся полученная информация не уляжется в голове по нужным местам сложно быть экспертом. Не зря ведь специалист со стажем ценнее чем без стажа. Не зря и 5 лет в вузах обучают. Человечеству это все уже давно известно и все ответы как бы на виду всегда есть. Научится бы их видеть во время...

Касаемо ООП в php, для меня это большой раздел который дает выбор разработчику. И что главное в php можно совмещать объектный стиль с процедурным.

Не имея достаточного опыта тему не нужно изучать с постулатов. Изучать нужно с частных примеров.
VeRTak
Цитата (casper - gg @ 5.03.2016 - 00:03)
И что главное в php можно совмещать объектный стиль с процедурным.


Так вроде об этом и писал Николай
casper - gg
Интересно вдруг стало. Если написать в официальную поддержку php с таким вопросом письмо "какой стиль лучше использовать при построении приложений?". Что же они ответят, неужели напишут - "можете использовать любой из стилей а также совмещать их одинаково успешно" laugh.gif
Arh
Wind
Ну тогда самый типичный пример, самой бытовой задачи.

У тебя есть проект, есть модуль "новости", который из базы получает новости.
Есть еще модуль или виджет (неважно как назвать, хоть плагин) который получает топ новостей из базы.
Есть модуль который выводит последнии 10 новостей из базы.
Есть модуль который выводит последнии 10 комментарий к новостям из базы.

Это 4 разных модуля, завязанные на одну таблицу/группу таблиц в базе.

В процедурке, в каждом модуле описана процедура получения того, что нужно.
То есть сделать запрос в бд, закешировать результат в файл, что бы каждый раз базу не дёргать, вывести в шаблон.

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

Тут придётся заходить в каждый модуль и править там подключение к бд, имя таблицы в запросе, если на новом сервере вдруг переименовал итд итп.

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

То есть проблема конечно решаема, но вот по такой методике.

А потом ты захотел написать еще 1 модуль, который тоже выводит новости, только там уже не хабр, а гиктаймс =)
Тут либо полностью копировать первый модуль новостей и менять там название таблиц и всё такое, либо в этом модуле писать какое то условие, процедуру.

В ООП это может быть так.
У тебя есть модуль новостей и все вышеперечисленные виджеты.
Нужно разом поменять базу, просто берёшь класс новостей и передаёшь туда другой объект DB, тоже самое с кэшем, просто кладёшь другой объект, который не в файл сохраняет, а в оперативку, а а класс новостей даже не заметит разницы.

А вообще ты даже ничего не подменяешь, ты просто настраиваешь контейнер зависимостей, но это отдельная тема для разговора =)





_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2
Arh
Вот кстати 2 вещи без которых я не представляю ООП в php, это принцип единой ответственности и паттерн - контейнер зависимостей.

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2
redreem
блин, не пишите тут ниче, не отвлекайте твина smile.gif а то его порвет smile.gif
Arh
redreem
Благодаря тому, что его прорывает, много народу скилл прокачивает, так что провоцируйте изо всех сил, без стеснения и без пощады laugh.gif

PS "порвет" не так прочитал, но всё равно)

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2
Invis1ble
Цитата (Wind @ 4.03.2016 - 23:08)
лично я не вижу почему использовать таблицы не каширно

сделай адаптивный сайт под любое устройство со сложной версткой и большим количеством динамики wink.gif

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

twin
Прорвало biggrin.gif

Цитата (Arh @ 4.03.2016 - 20:25)
Вот кстати 2 вещи без которых я не представляю ООП в php, это принцип единой ответственности и паттерн - контейнер зависимостей.

Тут вот в чем бяда. Ты про контейнер зависимостей, если мне не изменяет память, узнал год назад. А свою CMS пишешь намного дольше. Тебе кажется, что ты узнал что-то новое, и теперь твоя разработка на порядок круче. Может это и так, но чтобы применить этот паттерн, тебе пришлось очень много чего изменить. Очень много. Так в чем профит? Где эта прелесть:
Цитата (Arh @ 4.03.2016 - 20:20)
Нужно разом поменять базу, просто берёшь класс новостей и передаёшь туда другой объект DB, тоже самое с кэшем, просто кладёшь другой объект, который не в файл сохраняет, а в оперативку, а а класс новостей даже не заметит разницы.
?
А теперь представь, что завтра придумают еще более крутую фишку взамен DIC. Какой-нибудь элемент виртуального интеллекта, который будет сам решать, что где и когда взять и применить. Тебе придется опять переписывать всю свою поделку, дабы не отстать от моды.

Так эпизодически происходит при любой методологии. Сравни фреймворки десятилетней давности и современные. Небо и земля.

Недавно тема была, там даже в мой огород был брошен камушек. Там распираемые от гордости адепты объявили AVE.CMS отвратительной. Даже поленившись посмотреть, когда же эта разрабока была произведена на свет.

Мне было очень смешно. Люди называют отвратительным то, что писалось тогда, когда они даже "привет мир" написать не могли. Для своего времени (2007 год) это было вполне приличное приложение. Тогда так писали многие, и это были передовые технологии. PhpMyAdmin, SMARTY и многое другое, включая фреймворки, писались именно так. И это было на тот момент кононами ООП.

На сегодняшний день оно конечно устарело, но называть такие методы отвратительными, это примерно как называть отвратительным проводной телефон. А по сути об этом писал еще Крылов в басне про свинью и желуди.

Что происходит сейчас, это похоже на холивар яблодрочеров и смартфонофилов. Одни говорят - только айфоны! Это качество, красота и понты! Другие - айфоны зло! Они дороги и жрут батарейку!

На самом деле выходит новая версия айфона, и старая начинает считаться фуфлом и признаком нищебродства. Не говоря уже о самсунгах и иже с ними.

Вот и с технологиями программирования похожая ситуация. В той ветке человек искал специалиста по ремонту своего сайта. А ему говорят - это говно, нужно все переписать! Прмерно как я пришел в мастерскую по ремонту телефонов со своей нокией, а мне говорят - выкинь! Я это не хочу и не умею ремонтировать! Пойди купи айфон, причем шестой, тогда приходи. Смешно.

Никаких преимуществ у приложения на ООП в сколь видимой перспективе нет. Когда понадобится что-то изменить (базу там или что ты в пример приводил), может измениться куча технологий. И найдется очередной chee, который скажет - контейнер зависимостей, это вчерашний день, это отвратительно, нужно всё полностью переписать! Прогресс не стоит на месте, особенно когда мода диктуется обществом потребителей. Успевать за новыми технологиями, это значит не думать о будущем. Сейчас все делается одноразовым, включая и эти новомодные паттерны-шматтерны. Сегодня они в тренде, завтра станут "отвратительными".

И всё. Пикнули так восхваляемые заменяемость кода, преемственность и прочая лабуда, которая так активно сейчас пропогандируется адептами того, в чем они сам нифига не разбираются. Ибо, как я написал в статье, нет никаких критериев. Сегодня одно, через пять лет всё с точностью до наоборот.

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

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2025 Invision Power Services, Inc.