Использую ли я Объектную Модель

[jonjonson]

А новости я так не рассматриваю, т.к. они связаны с другими сущностями, например, у меня JOIN-ится таблица юзеров и групп. Поэтому без исправления этот класс можно было бы использовать только в 1 месте.

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

 

[Shturm]

WP
Смысл ООП я считаю не столько в том чтобы писать многократно используемые библиотеки (это легко можно сделать и без всякого ООП),
сколько в том, чтобы представить данные скрипта как "высокоуровневые" сущности, скрывающие в себе данные и реализацию методов работы с ними.
Именно разделение (и независимость) этих двух "слоев".

А наличие или отсутствие копипаста - я думаю это уже вопрос того,
насколько грамотно построена объектная модель.

jonjonson

Новости ничего не должны знать о пользователях

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

 

[WP]

jonjonson
А в чем смысл первогоначального класса тогда? Если почти все запросы будут другие. А проектирование нужно только там где оно нужно.
Shturm
Не скажи. Объекты дают удобство. Можно конечно заменить объект библеотеки функциями и передавать ассоциативный массив аналог $this, но нафиг это надо.

 

[Alexandre]

Смысл ООП я считаю не столько в том чтобы писать многократно используемые библиотеки (это легко можно сделать и без всякого ООП),
сколько в том, чтобы представить данные скрипта как "высокоуровневые" сущности, скрывающие в себе данные и реализацию методов работы с ними.
Именно разделение (и независимость) этих двух "слоев".

+1

Объекты дают удобство

+1

 

[grigori]

Автор оригинала: Shturm
вполне возможно что новость должна иметь представление, например,
об имени пользователя, чей ID она содержит в строке своих данных.

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

 

[Vallar_ultra]

grigori
Товарищи, ну вот опишите мне хоть один проект на котором тот-же xTPL или Smarty будет нагружать ТАК сервер? Шаблонизатор, если не на коленке писаный, вполне шустро бегает.

 

[axper]

стараюсь как можно меньше пользоваться классами...
я считаю, что PHP только тормозит от него, так как объекто-орентированный подход не настолько сильно развит в PHP, чтобы код работал с максимальной производительностью, как в C# например...

 

[Alexandre]

стараюсь как можно меньше пользоваться классами...

есть доля истины...
В связи со спецификой пхп, так как он является интерпретатором и каждый объект представляет - одну (две) хештаблицы, то соответственно большое использование объектов - ведет к большему объему памяти, к большем тормазам за счет косвенного обращения к методам юбъектов, в отличии от СиШарпа или жабы, где программный код компилится непосредственно в байт, а потом в набор машинных инструкций.

Но все же - хоть тормоза и есть, он не на столько, чтоб отказываться от использования объектов.

 

[ONK]

В рассматриваемом примере выбрал 4-й ответ.

Пояснения: При разработке подобного модуля я конечно использую готовые, необходимые ОО библиотеки, но не вижу смысла в разработке специализированного ОО кода для страницы новостей. Ценность этого кода равна нулю, использовать его в будущем всё равно не придётся. Написать в процедурном стиле, с использованием готовых библиотек, модуль вывода новостей это работа пяти минут (при наличии готового дизайна). Вобщем нет смысла тратить время на создание ОО решения для данной задачи.

 

[Alexandre]

Вобщем нет смысла тратить время на создание ОО решения для данной задачи.

ONK а для каких есть?

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

 

[ONK]

Alexandre, лично я использую ОО для создания библиотек (всего, что предполагается использовать более чем в одном месте), или для решения относительно сложных задач, где ОО подход к разработке позволяет сделать легко читаемое и удобное в сопровождении решение, разобранное на достаточно простые изолированные части.

Честно говоря, на данный момент, не вижу смысла в полностью ОО подходе к разработке web приложений на ПХП, демонстрируемом некоторыми из FrameWorks.

 

[AmdY]

Всё что я делаю, планирую использовать более одного раза. Поэтому только ООП.

 

[ONK]

AmdY, ничего страшного, это у вас с возрастом пройдёт.

 

[AP]

без ООП - вообще не могу!

 

[Апокалипсис]

В данный момент перехожу от пункта 3 к пункту 1

 

[Solid]

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

 

[tf]

дану

 

[Solid]

tf
ну да

 

[HraKK]

Solid
Только вы достиги истиного дзена!

 

[Solid]

HraKK
Прошу заметить, что мною не было сказано, что я гуру в ООП. Однако, смею сказать, что многие не понимают что есть ООП во всей его, так сказать, подлинности.
Настоящее ООП состоит из 4-х принципов: полиморфизм, инкапсуляция, абстракция данных, наследование. Когда что-то из этого, казалось бы, небольшого списка, отсутствует -- это уже не совсем ООП. Так же чаще всего ОО называют инкапсуляцию + наследование. Однако совсем забывают про абстракцию данных (одна из важнейших компонент ООП). Когда один из компонент потерян или используется не в полную силу, это уже называется "птица без крыльев". Иначе говоря, чаще всего то, что называют ООП вовсе не ООП, а структурное программирование, программирование при помощи кислых объектов... и не более того.