Как мыслить объектами?

Question

[Алексей]

Всем привет! Постоянно, чуть не во всех мануалах и в комментариях на форуме пишут, что нужно мыслить объектами в ООП. И приводится пример по типу: есть шар, у него есть радиус, масса, и т.д. (это свойства). Шар может катиться, лететь и т.д. (это методы).
Но, как перевести это в программирование... Мне нужно создать класс комментариев и тут ступор... Ведь понятное дело, если мыслить объектами, то комментарий должен быть один...
У комментария есть свойства: автор, текст, рейтинг.
И методы: отобразить комментарий, удалить комментарий.

Но куда девать такие методы как: Получение комментариев для фотографии, вывод всего списка комментариев и так далее? Ведь выкидывать их в отдельную функцию это как-то не рационально и наверное не правильно... так можно растерять весь код. Как это все тогда соединить в более правильную структуру?

Comments

[RokkerRuslan]

Вы всю жизнь объектами мыслите

[Владимир]

Проблема с ООП в том что все термины в программировании и разработке приложений это иностранные слова, которые в лучшем случае мы можем перевести. Для того чтоб разобратся в чем-то нужно перенести "проблему" в жизненную плоскость.

Например: у шара неможет быть метода "катится" потому что как бы он не хотел он не может сам себя покатить. Но человек может покатить шар. У класса человек может быть метод "кушать", а вот метод "накормить" уже не привязан к конкретному человеку (т.е. должен быть статичным) т.к. кормить кого-то необязательно нужно делать самому человеку: дай еду, другой человек сам поест (даже если эти два обьекта один и тот же человек). Комментарий не может добавить сам себя, только человек (пользователь) может добавить комментарий. Если посмотреть на это под другим углом то можно сказать что: комментарий это сообщение у которого есть автор и "цель", целью может быть статья, новость, фаотка или другой комментарий/сообщение.

В серверной разработке часто все классы делят на 2 группы: модели, контроллеры (так же как и в паттерне MVC). Модель используется для представления, хранения и передачи данных. А контроллеры занимаются тем что управляют ими (создают, удаляют, меняют), обмениваются данными между собой итд итп.

[Владимир]

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

[Владимир]

Neoline: действительно зачем усложнять все, ведь можно по старинке налепить "че попало" ic.pics.livejournal.com/goblin_books/55025230/2011...

[Владимир]

Neoline: аргументы и обьективность потерялась сначала в вашем комментарии, как раз в том на который я и ответил сарказмом и картинкой. Касательно ООП и паттернов - нравится или нет есть только 2 вида кода: ООП код и процедурный, и то что происходит в реальном мире большее похоже на ООП код чем на процедурный. А шаблоны (они же паттерны) в реальном мире везде используются, они не добавляют никакой сложности в код как и не убавляют, ведь их надо применять тогда когда они нужны. А для того чтоб знать когда этот момент наступил надо в них разбиратся чтоб не "лепить ооп где надо и не надо"

[Владимир]

Neoline: я так понимаю вы снова делитесь своим опытом. А моем все было по другому: большую часть простых паттернов я научился использовать еще до того как почитал теорию. К освоению теории я пришел намного позже поэтому сразу получил "толчек" в развитии. Мое мнение: паттерны не какая-то заоблачная теория которую придумали профессора в белых халатах а еще две ступеньки на пути которые надо освоить (теория, практика). А если вы вспомнили о том с чего все началось то: автору как раз SOLID нужен хотя вы рекомедуете не разбиратся с этим, на этом этапе паттерны автору не нужны это факт, но это еще не значит что то что случилось с вами: "будите разбираться вообще запутаетесь" постигнет всех.

Answer 1

[Виталий]

Господа, не нужно ничего усложнять - всё до безобразия просто))

Когда вы говорите КомментариЙ - это и есть ваш объект.
Когда вы говорите КомментариИ - это уже массив объектов: контейнер, коллекция - не знаю на чём конкретно программируете, буду называть списком (массивом называть неправильно).

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

Рассматривайте модели объектов (классы) как описание системы (фрагмента из реального мира). С такой системой могут общаться другие системы: что-то сообщать, о чём-то просить сделать или сообщить.

Answer 2

[xmoonlight]

Учите и учитесь применять шаблоны проектирования.
www.phptherightway.com/pages/Design-Patterns.html
designpatternsphp.readthedocs.io/en/latest

Answer 3

[Антон Зеленский]

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

Comments

[Алексей]

Я привел конкретный пример с комментариями, причем тут реальный мир

[Антон Зеленский]

Евгений: наверное при том, что вы – реальны (я надеюсь), объекты, которые вы затрудняетесь описать – реальны. Это все из реального мира.
А ассемблер и си – это мир нереальный. И вот эту дистанцию между нереальным миром единичек и нулей и реальным миром вашего сознания вроде как и должен был заполнить ООП по своей идеологии. Но, видно, что-то пошло не так.

[Алексей]

Антон Зеленский: Вы скорее всего не правильно поняли вопрос... Я могу представить что такое комментарий и какими свойствами он обладает... Проблема в том, чтобы совместить группу комментариев, действия над ними и каждый отдельный комментарий из этой группы. Отдельно, я понимаю практически каждую возможность ООП, а на практике появляется ступор из-за соединение этого всего воедино. В итоге получается хоть и рабочий, но с точки зрения кода, не красивый и не правильный класс.

[Алексей]

Антон Зеленский: У меня получается класс Comments, и я работаю с ним так:
$comm = new Comments($db, $tpl);
$comm->setParams(Тут массив параметров или отдельный параметр для получения комментариев из базы)
$comm->getComments() // Получаю комментарии в виде массива
$result_comments = $comm->showComments() // А тут собираю их в html код (шаблонизатор $tpl передается конструктору)
Ну и дальше вывожу $result_comments на страницу. Все.

И тут я понимаю, что где-то должен быть еще один класс, который в методе showComments() описывает каждый комментарий из массива и выводит его как html код, и только потом какой-то другой метод собирает их воедино.

[Алексей]

Антон Зеленский: И вот оно всё работает и работает правильно вообще без каких-то нареканий. Но я почему-то хочу научиться писать красивый код, хотя в данном случае в глубине души я понимаю "зачем мне усложнять мой метод еще какими-то классами, если все умещается в десяток строк кода в одном методе"

[Антон Зеленский]

Тут вы правы. Я исходил из вашего заголовка: «Как мыслить объектами?». Задача такого содержания ставилась не перед вами, а перед ассемблером и си до появления ООП. Так ООП и появился.
По сути же вашей фактической задачи, вопрос, по-видимому, в том, как вам правильно собрать представляемое в архитектурном смысле слова. В комментариях выше в общем ответ дан. Любая книга, разбирающая принципы SOLID, мне кажется, полностью снимет ваш вопрос.

Answer 4

[marrs]

Это тот случай, когда проще научиться, чем объяснить

Answer 5

[Максим Мосейчук]

Но куда девать такие методы как: Получение комментариев для фотографии

В класс "фотография".

Answer 6

[Vitaliy Orlov]

Получение комментариев для фотографии - в класс фотографии ( Photo.getComments() )
Вывод всего списка комментариев - можно в коллекцию комментариев ( CommentsCollection.findAll() который вернет массив комментариев [Comment, Comment, Comment, ...])

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

Так же не бойся делить все на много классов и методов - это правильно! Возможно тебе еще рано, но почитай в википедии про принципы SOLID.

Comments

[Vitaliy Orlov]

OnYourLips: Не, меня не смущает

[NataliaCh]

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

Answer 7

[xfg]

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

Поверьте, в одном сообщении невозможно описать как строить архитектуру приложения. Но понять основные принципы проектирования можно почитав книгу Vaughn Vernon - Implementing Domain-Driven Design. Но эти принципы популярны в энтерпрайз сегменте со сложной бизнес-логикой и большими бюджетами, в основном на языке Java (качественно, дорого, медленно). Типичные интернет-приложения в своей массе используют другой подход, там объекты это скорее контейнер для функций, объединенные по принципу "так решил разработчик", у тех кто знает о solid/grasp немного получше, у тех кто нет - немного похуже, но в целом это подход - бысто, дешево, менее качественно и в целом, не особо отличается от процедурного программирования.

Answer 8

[di23]

По принципу матрешки. Один объект может содержать другой объект, а тот в себе третий и т.д.
Те методы которые у вас не влезли в структуру явно не относятся к Комментариям. Нужно создавать другие объекты, Списки Комментариев, Фотография, а те в свою очередь будут частью других объектов, более "крупных".
Объект должен управлять сам собой, менять свое внутреннее состояние, но не влиять на внешний мир. Если нужно повлиять на что-то внешнее - это значит вам нужен другой объект, вот туда пихаете ваш объект и это "внешнее" и колдуйте как химик.

Answer 9

[Neznayka xD]

Книга:
«Объектно-ориентированное мышление» Вайсфельд М.