Всем привет.
Начинаю осваивать ооп, и появилась одна проблема, точнее не понимание как ее правильно решить...
И так есть 3 сущности:
1. Пользователь в системе
2. Пост пользователя
3. Лента

У сущности пользователя есть свойства (логин пароль и т.п), одно из действий написать пост.
Для этого действия я решил вынести пост в отдельную сущность (по сути это так и есть), пост можно добавить в избранное и т.п
Также есть лента, пока тока лента постов, в эту ленту передается объект поста.
В действии написать пост, сначала создается объект поста, потом он помещается в ленту..
И все нормально вроде бы, но появилась необходимость сделать как бы рассылку 1 записи в несколько лент других пользователей, исходя из ооп, можно создать несколько десятков объектов лент, и отдать им туда объект записи...

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

Ps Извиняюсь за эту статью

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

незачем запихивать каждому в ленту.

в любом случае никаких проблем с ООП здесь нет, тем более что рассылку вообще делают через крон а там ООП нафиг не надо.

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

А как тогда?
(Добавление)
То есть в этом случае, лучше реализовывать без ооп правильно я понимаю?
Не создавать объекты пользователей и т.п

есть ощущение, что вопрос больше не про ооп, а про архитектуру приложения в целом ;) а какой из элементов этой архитектуры будет объект, а какой массив - это уже дело техники.

что-то посоветовать можно, но чтобы ответ мог получиться более адекватное, нужно понять скилл реципиента ;) а именно, какие книги прочитал, посомтреть примеры кода, который реципиент готов показать, какими технологиями и библиотеками владеет, какие цмс-ки и фреймворки изучил внутри... и самое важное - для чего это всё ему надо? ;))))

а смысл дублировать тот же объект по всем лентам?



объект пользователей как я понимаю служит не только для рассылки.
просто у некоего обекта именеюмого напрмер "рассылка" будет метод
который делает собственно рассылку или запихивает данные в Бд или еше куда. Просто метод с нужными SQL запросами. Это и есть ООП - обхект выполняет работу которая принадлежит к его логике.
(Добавление)

симфони он не учил - так что адекватного ответа у тебя никаким каком не получится

Ну как бы изначально объект лента принадлежит объекту пользователь, или проще у пользователя есть лента)
И что бы разослать другим пользователям (друзьям или еще кому), как бы сначала нужно из бд воссоздать объекты этих пользователей, а потом к каждому из них применить типа $user->addLenta($post)
Понятное дело что так это очень и очень затратно, но разве это не логично с точки зрения ооп?

это нелогично с точки зрения архитектуры. Тем более это касается PHP у которго нет персистентных объектов. Определенный смысл это могло бы иметь например в ява машине когда объект живет в памяти и к нему можно прикнопить другой объект.

в данном случае нет никакой необходимости добавлять объект, достаточно добавить id объекта. а когда будет формироватся лента на странице по этим id вытащатся данные с рассылки.

но лучше все таки не делать никакую ленту. Есть рассылки и есть пользователи. должна быть кросс-таблица которая связывает пользователей с рассылками. По сути подписка или список рассылки. по этой связи и вытянется вся лента (во всяком случае то что касается рассылки).

caballero
Ок, буду лепить класс рассылок для пользователей, хотя тема довольно интересная...
Спасибо за разъяснение...

сделать все подряд объектами нет смысла
в теории одно а практика это совсем другое

это как в реляционной алгебре - все знают что БД должна быть нормализована до 5 формы, но в реальности это чревато сложными много табличными запросами. Поэтому есть даже такое понятие как денормализация - когда хранятся избыточные дублирующие данные но зато запросы линейные на одну таблицу и в результате производительность больше. или например хранят предварительно вычисленные агрегации. особенно это касается mysql у которого оптимизатор уступает промышленным серверам БД

Про алгебру не знаю пока еще не доучился))
А вот про денормализацию в бд знаю, например в mongo это даже считается в порядке вещей...