Может кто-нибудь дать реальную задачу на которой можно применить ООП?

ООП очень тяжело заходит потому что совершенно непонятно для чего оно нужно. Я так понял, что бы в этом всём разобраться нужно писать свою CMS на ООП. Но, нужно писать её не от фонаря, а поглядывая на какую-то CMS как на пример. Где найти такую не очень сложную CMS что бы новичок смог в ней разобраться?
  • Вопрос задан
  • 890 просмотров
Пригласить эксперта
Ответы на вопрос 12
Fockker
@Fockker
Потомок старинного рода Ипатьевых-Колотитьевых
Это хороший вопрос, но однозначного ответа на него нет.

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

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

В-третьих, все реальные примеры настолько замороченные, что по ним разобраться совершенно нереально. А упрощенные ничего толком не показывают. Только синтаксис.

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

Это пример самой базовой и очень распространенной задачи - как сделать работу с SQL менее занудной и гарантированно безопасной. И начинать надо именно с таких задач, не замахиваясь на приложения целиком.

Если говорить о приложении целиком, то стоит попробовать написать что-то примере фреймворка Symfony - это как раз даст понимание того, как ООП применяется на уровне приложения.
Ответ написан
sergey-gornostaev
@sergey-gornostaev
Седой и строгий
Парадигмы нужны для управления сложностью. Соответственно их надобность начинаешь замечать и понимать в действительно сложных проектах. Причём просто скачать откуда-то сложный код взрослой системы вряд ли будет достаточно, надо несколько лет поддерживать и развивать такую систему в большой команде, часть которой за эти несколько лет ещё и сменится.
Ответ написан
VoidVolker
@VoidVolker
Разработчик ПО и IT-инженер
ООП очень тяжело заходит потому что совершенно непонятно для чего оно нужно.

Ровно для того же, для чего нужно программирования без ООП. ООП - просто достаточно простая и удобная абстракция для программирования.

Я так понял, что бы в этом всём разобраться нужно писать свою CMS на ООП.

Нет. Достаточно просто решить любую задачу с использованием ООП и без и сравнить для себя. Без ООП, т.е., функциональное программирование - у тебя куча файлов с кучей функций, каждый раз, когда нужно произвести какие-то вычисления над какими-то данными надо импортировать нужную функцию и использовать её для обработки данных. Когда у тебя десять строк кода и три функции - это достаточно просто. А если у тебя тысяча функций и несколько сотен видов данных для обработки, да еще и кучей разных форматов? А десять тысяч? Делать огромную документацию, в которой описывать какая функция с какими видами данных может работать и каждый раз её пересматривать в процессе написания или чтения кода? А вот ООП, говоря простым языком, позволяет группировать функции в отдельные группы, т.е. классы, которые могут работать с определенными типам данных и связывать сами эти группы функций с определенными типами данных, а так же связывать классы друг с другом (иерархия, наследование и прочее). Т.о., это упрощает работу с данными и их обработкой: просто создаем новый экземпляр класса и получаем удобный интерфейс для дальнейшей обработки каких-либо данных, путем использования методов этого класса для обработки данных, хранящихся в полях данного экземпляра или передаваемых в качестве параметров методов и сохраняемых в полях позднее.
Ответ написан
HemulGM
@HemulGM
Delphi Developer, сис. админ
Сколько фигни понаписали, а человек просто просил реальный пример для применения ООП.

ООП помогает строить приложения так, как человеку удобнее мыслить. Наш мир окружают объекты. И в программировании мы описываем эти объекты. Например: человек - объект. Человека мы можем описать не целиком, если нам нужен человек только лишь как клиент. А для этого нам важен его идентификатор, имя и прочие данные.
После чего мы используем списки таких объектов для манипуляции данных. Список клиентов - список объектов.

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

Что то типа Client.CreateOrder (клиент создает заказ) или Orders.CreateOrder(Client) (менеджер заявок создает новую для такого-то клиента).
Всё достаточно просто.

Тебе достаточно придумать любую задачу и просто решить её с помощью объектов.
Например, музыкальный плеер. Пусть трек будет представлять объект, содержащий путь к файлу, название, продолжительность и так далее. И список треков. Дальше сам решай кто чем будет управлять. Либо ты работаешь над списком объектов, либо каждый объект может сам делать что нужно. Но для музыкального плеера удобнее, когда треки лишь содержат данные (DTO). Т.е. имеем список треков и манипулируем объектами (добавляем, редактируем, удаляем и т.д.)

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

TAudio = class abstract
private
  FId: string;
protected
  function GetTime: TTime;
  function GetName: string;
public
  property Id: string read Fid write FId;  //Пусть тут будет полное имя файла или ссылка на веб
  property Time: TTime read GetTime;  //Время
  property Name: string read GetName;  //И имя
end;

После чего мы можем от него наследовать два класса (для файлов и для веб)
TAudioFile = class(TAudio)
protected
  function GetTime: TTime; override;
  function GetName: string; override;
end;

TAudioUrl = class(TAudio)
protected
  function GetTime: TTime; override;
  function GetName: string; override;
end;


И хранить оба типа объектов в одном списке.
TAudioList = TObjectList<TAudio>;

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

Используя список мы можем
var AudioList := TAudioList.Create;

var Audio: TAudio := TAudioFile.Create('C:\Music\Track1.mp3');
AudioList.Add(Audio);  // Добавлять аудио файлы

Audio := TAudioUrl.Create('webmusic.ru/tracks/track1.mp3');
AudioList.Add(Audio);  // Добавлять веб аудио 

AudioList.Delete(0); // Удалять элементы

// менять местами, сортировать, редактировать и т.д.


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

Player.Play(AudioList[0].Id);

А дальше мы можем усложнять и усложнять, добавляя новые возможности. Например, завести интерфейс и принимать аудио файлы из плагинов. Или использовать ОРМ для хранения плейлистов в базе данных. Мы можем отличать один вид от другого при переборе списка и обрабатывать уникально для некоторых.
Ответ написан
Real_Fermer
@Real_Fermer
Программист PHP
Понимание - зачем придет тогда, когда перестанете радоваться, что у вас хоть что-то работает. И начнете развивать свои приложения. Тогда поймете что поддержка приложения - это очень важная задача.
Сделайте 5-6 небольших приложений - не применяя никаких техник/методик разработки.
отложите их на месяц. А потом вернитесь и попробуйте внести изменения. Тогда вы поймете зачем нужны методики разработки.
А для приложений HellowWord Не нужны ни ОПП, ни паттерены, ни уж тем более фреимворки
Ответ написан
Комментировать
firedragon
@firedragon
Senior .NET developer
https://habr.com/ru/post/87205/
читайте ООП в общем то делалось для удобства, как и паттерны
Ответ написан
Комментировать
php666
@php666
PHP-макака
вот же людям не лень писать портянки каждому новичку на одни и теже вопросы..

гради буч объектно-ориентированный анализ и проектирование
Ответ написан
Комментировать
@JustMoose
Программист. Радиолюбитель. Прокрастинатор ;)
Про ООП есть прям отличная книжка: Гради Буч, Объектно-ориентированный анализ и проектирование.

ЗЫ: осторожно выскажу своё мнение, что ООП нужно для удобства. Ибо банально удобнее, когда твои данные лежат рядом с методами их обработки. А не размазаны тонким слоем по всему модулю, что не понять, где чьи данные, и какими функциями они обрабатываются.
Ответ написан
DollyPapper
@DollyPapper
В том беда современного обучения программированию, что учат ООП на наследовании кошечек и собачек от абстрактных животных, а нахера это делать и зачем это появилось не учат. Плохая для вас новость - вы не поймете прелести подхода пока не проработаете хотя бы годик на реальном проекте. Но понять сам ООП вы можете не работая. Попытаюсь натолкнуть вас на мысль, и обьяснить истоки, откуда пошло ООП и зачем, через какое-то время вы осознаете эти концепции. Итак.
Когда мы пишем программу, мы так или иначе моделируем какую-то часть реальности. Модель это несовершенное представление самой этой реальности, с выделенными атрибутами необходимыми для нашей решаемой задачи (абстрагирование, один из принципов ООП), например детская игрушка самолет, это модель реального самолета который копирует лишь внешний реального самолета, при этом игнорируется его внутреннее устройство, и игрушка таким образом не умеет летать, но наша задача (развлечь ребенка) при этом выполняется.
Существует несколько парадигм праграмирования. Каждая парадигма это стиль моделирования программы. Затронем например процедурное программирование. В нем существуют для моделирования задачи такие сущности как: структуры данных и процедуры которые эти структуры обрабатывают. Дело в том, что в программе есть всего две еденицы которыми мы управляем: данные и поведение. Структуры данных это собственно данные, процедуры это поведение. Смысл зачем появилось процедурное программирование именно чтобы дать программисту абстрагировать поведение (засунуть код обработки данные в именованную сущность, она еще называется функция или процедура). Что это нам дает? Раньше у нас была простыня кода которая расчитывала например зп сотрудников, если нам нужно было посчитать зп в разных местах нам нужно было копипастить эту простыню. А сначала нужно было разобраться что простыня делает. Это сложно. Теперь у нас появилась именованная сущность (процедура) которпя имеет метку имени calculateSalary. Ну и что? А то, что теперь нам во первых не нужно копипастить код, во вторых (в идеале) не нужно разбираться как он работает. Мы просто знаем что calculateSalary считает зп для сотрудника. Как оно это делает, нам совершенно похер. Снизилась когнитивная нагрузка на мозг при моделировании задачи и повысилась переиспользуемость кода, тем самым сократилось время разработки. Но умные люди на этом не остановились и стали развивать идею дальше. Дальше они подумали, что не плохо было бы обьеденить в одной сущности данные и действия над этими данными, назвали это обьектами, которые могут формироваться на основе классов. Теперь у нас обьеденены данные и процедуры в одной именованной сущности (это инкапсуляция). Подробнее об инкапсуляции можете почитать в другом моем ответе https://qna.habr.com/q/1174988#answer_2194198
В общем вы не поймете прелесть ООП пока не поработаете по той причине, что нужно набрать массу сложности в проекте, которую генерируете как вы сами так и другие программисты, и не поймете прелесть повторного использования кода которое дает ООП, потому что у вас нет горящих сроков. Тут еще можно в целом много чего написать на тему ООП, но я бы вам посоветовал следующие книги:

Стив Макконел - Совершенный код
Гради Буч - Обьектно ориентированный анализ и проектирование
Сергей Типляков - Паттерны проектирования на платформе .NET (это вместо банды четырех, т.к. там более современно раскрывается тема паттернов, не пугайтесь что она про C# .NET, книга в самом деле очень хорошая)

Так же список терминов на погуглить
GRASP - Information Expert
Information Hiding
Software Complexity (это то откуда всё начинается, управление сложностью)
Cohesion & Coupling

Если вы все эти темы осознаете, то будете понимать в ООП и проектировании больше 95% ваших будующих коллег, я вам гарантирую.
Ответ написан
@aGGre55or
Ответ на ваш вопрос на самом деле предельно прост. Такой задачи не существует в природе. Не существует задачи которую можно решить с использованием ООП и нельзя было бы решить без ООП. Классическим примером является трансляция C++ в чистый Си с последующим ассемблированием и компиляцией в машинный код. Представьте что на вашей кухне соль всегда должна лежать в синей банке, сахар - в красной, а крупа - в зелёной. И не задавайте вопроса: почему? Потому что это стандарт. Точно также применение ООП является стандартной методологией разработки и не более того. Если вы видите что кто-то начинает рассказывая про ООП цитировать Конфуция - смело посылайте его на хутор. И вы сразу увидите что доля ООП "без Конфуция" ничтожна мала, можно сказать что это фундамент существования данной методологии даже там где она принципиально не нужна и более того - вредна. Но со стандартами не спорят, так же как не спорят с ПДД или Уставом караульной службы.
Ответ написан
@Awasaky
Поймите простую вещь - ООП можно применять только тогда, когда без него нельзя обойтись. Даже в условно объектно-ориентированных языках. Если вы можете реализовать задачу не задействуя ООП - тем лучше для вас.
Ответ написан
Комментировать
EugeneOne77
@EugeneOne77
Laravel, Vue, Wordpress разработчик.
CMS не обязательно. Что бы разобраться можно посмотреть курс Дмитрия Лаврика про ООП.
Если про задачу - вот пример, из моей практики. Немного корявый, но для изучения самое то.
В разных местах нужно записывать определенные данные пришедшие от пользователя на диск либо в базу данных. (можно еще в Redis, если понятно что это), в зависимости от... ну допустим типа пользователя. Перед тем как эти данные записывать, нужно сделать несколько стандартных проверок.
Соответственно нужен объект, который будет
хранить данные,
проверять их,
сам выбирать способ записи,
выдавать определенную ошибку если данные не прошли проверку
и иметь стандартную процедуру записи. (что-нибудь типа saveData() )
Желательно предусмотреть так, что бы способ записи был расширяемый, т.е. возможно будут еще какие-то другие хранилища, а значит нужны интерфейсы для классов, т.е. наш объект должен принимать объекты которые непосредственно делают запись на какой-то носитель.
p.s. профессионалов просьба не ругаться, понятно, что с тестированием, DI и прочими классными штуками решение будет несколько другое.
Ответ написан
Ваш ответ на вопрос

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

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