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

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

Но куда девать такие методы как: Получение комментариев для фотографии, вывод всего списка комментариев и так далее? Ведь выкидывать их в отдельную функцию это как-то не рационально и наверное не правильно... так можно растерять весь код. Как это все тогда соединить в более правильную структуру?
  • Вопрос задан
  • 3044 просмотра
Пригласить эксперта
Ответы на вопрос 10
vitali1995
@vitali1995
Господа, не нужно ничего усложнять - всё до безобразия просто))

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

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

Рассматривайте модели объектов (классы) как описание системы (фрагмента из реального мира). С такой системой могут общаться другие системы: что-то сообщать, о чём-то просить сделать или сообщить.
Ответ написан
Комментировать
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Комментировать
OnYourLips
@OnYourLips
Но куда девать такие методы как: Получение комментариев для фотографии, вывод всего списка комментариев и так далее? Ведь выкидывать их в отдельную функцию это как-то не рационально и наверное не правильно... так можно растерять весь код. Как это все тогда соединить в более правильную структуру?
Этим вопросом задавался любой программист.
И есть даже однозначно правильный правильный ответ: в репозитории.

Это PhotoRepository, CommentRepository и т.д. классы соответсвенно.
Новички же обычно это пихают в классы Photo и Comment (вам уже такие ответы дали к этому вопросу), в итоге получают неподдерживаемый код. Этот антипаттерн называется GodObject (или его частный случай ActiveRecord), так делать нельзя (нарушение принципа единственной обязанности).

Читайте про основные принципы ООП, которые называются SOLID.
Ответ написан
Парадокс: ООП родилось, чтобы приблизить мир кода к реальному миру. И вот человек из реального мира спрашивает, как мыслить ООП.
Ответ написан
@marrs
Это тот случай, когда проще научиться, чем объяснить
Ответ написан
Комментировать
Но куда девать такие методы как: Получение комментариев для фотографии

В класс "фотография".
Ответ написан
Комментировать
orlov0562
@orlov0562
I'm cool!
Получение комментариев для фотографии - в класс фотографии ( Photo.getComments() )
Вывод всего списка комментариев - можно в коллекцию комментариев ( CommentsCollection.findAll() который вернет массив комментариев [Comment, Comment, Comment, ...])

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

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

Поверьте, в одном сообщении невозможно описать как строить архитектуру приложения. Но понять основные принципы проектирования можно почитав книгу Vaughn Vernon - Implementing Domain-Driven Design. Но эти принципы популярны в энтерпрайз сегменте со сложной бизнес-логикой и большими бюджетами, в основном на языке Java (качественно, дорого, медленно). Типичные интернет-приложения в своей массе используют другой подход, там объекты это скорее контейнер для функций, объединенные по принципу "так решил разработчик", у тех кто знает о solid/grasp немного получше, у тех кто нет - немного похуже, но в целом это подход - бысто, дешево, менее качественно и в целом, не особо отличается от процедурного программирования.
Ответ написан
Комментировать
@di23
По принципу матрешки. Один объект может содержать другой объект, а тот в себе третий и т.д.
Те методы которые у вас не влезли в структуру явно не относятся к Комментариям. Нужно создавать другие объекты, Списки Комментариев, Фотография, а те в свою очередь будут частью других объектов, более "крупных".
Объект должен управлять сам собой, менять свое внутреннее состояние, но не влиять на внешний мир. Если нужно повлиять на что-то внешнее - это значит вам нужен другой объект, вот туда пихаете ваш объект и это "внешнее" и колдуйте как химик.
Ответ написан
Комментировать
Neznayka1979
@Neznayka1979
Интересы - IT, психология...
Книга:
«Объектно-ориентированное мышление» Вайсфельд М.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы