В каких случаях использовать ООП?

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

UPD 05.10.2017.
С добавлением функционала, немного начинает прояснятся суть ООП. Изменить функции на методы объектов правильнее, так, как читать код стало легче, и понятно какой объект за какую функцию отвечает. Как один из примеров.
  • Вопрос задан
  • 1492 просмотра
Решения вопроса 2
@GreatRash
ООП нужно использовать только тогда, когда вам от этого становится удобно. Вообще все парадигмы в программировании придумываются для того, чтобы сделать удобно себе и окружающим.

Если вы:
  • пишете один
  • делаете одноразовые проекты (лендинги например)
  • никогда повторно не используете ранее написанный код

то вам этот ООП будет только мешать.

Если вы:
  • работаете в команде
  • пишете большой проект (приложение например)
  • вы и ваши коллеги постоянно используют куски ранее написанного кода

то вам без ООП будет очень сложно обойтись.

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

Особенности:
  • - нет необходимости применять ООП для очень мелких программ/скриптов
  • + желательно использовать в программах, которые потребуется поддерживать и улучшать
  • + необходимо использовать в больших программах (чем больше функций должно выполнять ПО, тем сложнее будет их все правильно структурировать и реализовать)


Например, в самом простом калькуляторе нет необходимости что-то представлять в виде объектов, достаточно функционального стиля (все что от него требуется, это методы add, sub, div, mul и т.д.)
Если что-то посложнее, тогда с одними функциями будет сложно работать, и будет сложнее разбираться в коде (поддерживать его) и понимать какая часть кода за что отвечает (нажатие кнопки, вывод результата).
В случае с ООП можно такие компоненты представить в виде классов, тем самым оградить нужные данные и методы от остальных (классы Button, Field, и Operation, например). Конечно, и кода станет больше, но зато потом будет легче в нем разобраться, чем перебирать все функции и места, где они выполняются.
3 принципа ООП:
  • инкапсуляция - изолирование некоторых данных и методов от прямого внешнего воздействия
    Например, у Button есть имя, но оно не должно быть доступно как public, чтобы его не могли изменять как попало, а изменять только через метод setName, который будет контролировать что можно ставить как имя кнопки, а что нельзя

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

  • полиморфизм - позволяет работать с данными не заботясь о том, какие дополнительные свойства имеют эти данные (объект) или какого они типа
    Например, есть класс Месседжер, он имеет метод отправить(что-то). В виде параметра нужно передать то, что нужно отправить, а это может быть как текст, так и файл. Это пример статического полиморфизма (хотя в JS его трудно назвать таковым, так как он с динамической типизацией и не имеет перегрузки методов, и все разборки по поводу того, что делать с данными разного типа происходят при выполнении программы). В динамическом необходимо знать только то, что умеет делать определенный объект и не важно чем он есть на самом деле и как он это делает (см. пример с классом Транспорт выше)

Ответ написан
Пригласить эксперта
Ответы на вопрос 1
usdglander
@usdglander
Yipee-ki-yay
ООП лучше юзать всегда. Конечно если нужно сложить пару чисел, то городить диаграмму классов смысла нет, но если что то более-менее серьёзное то лучше всё таки ООП. Всё то же самое можно сделать и без ООП, но вот ООП-подход позволяет писать понятный, сопровождаемый и надёжный код.
Ответ написан
Ваш ответ на вопрос

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

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