Сегодня мы обсуждаем ООП (объектно-ориентированное программирование) с точки зрения самых-самых новичков. Этот термин довольно часто встречается в программе учебных курсов, и новички не всегда могут понять, что именно им нужно знать. Давайте обо всём этом поговорим.
Парадигмы программирования
ООП — это парадигма программирования. Парадигма — это способ взгляда на что-нибудь, набор шаблонов мышления. Когда мы смотрим на что бы то ни было, мы это воспринимаем через некую призму, парадигму. Так работает человеческие мышление. Например, вы хотели узнать, есть ли на улице места для парковки, соответственно оказавшись на улице, мозг выхватывает информацию о наличие парковочных мест и кем они заняты. Сейчас для вашего мозга улица — это набор парковочных мест. Или вы можете оценивать ситуацию на улицы с точки зрения погоды или по еще каким-то аспектам.
Применяя это к программированию, парадигма означает, на что мы будем разделять предметную область или то, что мы собираемся автоматизировать. Помним, что программирование — это про автоматизацию чего-то. Для того чтобы автоматизировать, мы должны в голове разделить задачу (декомпозировать) на какие-то элементы. Вот какие элементы мы получим, от этого будет завесить и разница парадигм. Просто последовательное выполнение задач, т.е. разделение на алгоритмическую последовательность действий.
В какой-то момент программисты подумали и поняли, что одни и те же действия выполняются регулярно, но над разными данными, соответственно почему бы не выделить это в одну процедуру. Так появилась процедурная парадигма.
Процедурная парадигма
В рамках такой парадигмы программист разделяет все происходящие действия на процедуры. Например, мы вызываем какую-то одну процедуру с одними данными, потом её же с другими данными, потом вызываем какую-то ещё процедуру и так далее. Мы не выполняем все действия подряд, а рассматриваем задачу как набор вызовов процедур.
Процедурная парадигма существовала очень долго и существует до сих пор, есть большое количество языков программирования, которые работают исключительно в процедурной парадигме. Например, до сих пор популярен язык С и он тоже использует процедурную парадигму. Этот язык применяется для написания программ для не особо мощного железа, обычно это встроенное железо: бортовые компьютеры автомобилей, самолётов, а также каких-то маленьких устройств и т.д. В этих случаях как раз часто используется язык С, потому что это простая парадигма, не требующая каких-то больших ресурсов от компьютера.
Основная проблема заключалась в том, что процедурная парадигма понятна и удобна, когда разработчик пишет достаточно небольшую программу. Но в реальном мире существуют большие и сложные задачи, над которыми работает огромное количество разработчиков. В этот момент внезапно выясняется, что большая программа, состоящая из процедур, абсолютно не поддерживаемая.
На заре своей программистской карьеры я работал над такой программой. У нас был файлик, куда мы скидывали все наши процедуры. В результате их накопилось столько, что найти нужное там было невозможно, потому что невозможно нормально отсортировать и разложить по разным файлам и каталогам. Вы имеете разные процедуры, но по какому параметру их сортировать? По букве? Цифре? Количеству? По связанности с чем-то? Когда я наконец занялся рефакторингом (наведением порядка в коде), в результате оказалось, что там было огромное количество процедур, которые назывались, условно «Слово 1 Слово 2», а некоторые «Слово 2 Слово 1». Как так вышло? Какой-то программист не нашёл нужную процедуру и написал свою, точно такую же, но с другим названием. Были некоторые процедуры, которые ничего не вызывали. При этом по современным меркам это была очень маленькая программка, но на ней работало больше 10 разработчиков. В итоге получилось черт знает что.
Поэтому программисты поняли, что так не работает, что нужно разделять программы на какие-то осмысленные блоки. Так и возникло объектно-ориентированное программирование (ООП). Или, по-другому, объектно-ориентированная парадигма.
Объектно-ориентированная парадигма
Вся предметная область в ООП воспринимается как набор объектов. Объекты — это данные, их состояние и их поведение. Под поведением понимается то, как с объектом можно обращаться и за какие методы его можно дергать. Таким образом мы получаем гораздо более логичное разбиение программы на блоки. Потому что если у вас есть какая-то предметная область, которую вы собираете автоматизировать (например, завод, магазин, спорт клуб и пр.) там в любом случае есть какие-то объекты. Есть объект Занятия, есть объект Покупка, есть объект Товар, есть объект Чек и так далее. Вот у всех этих объектов есть состояние: есть цена этого чека, дата, кто купил и пр. Есть поведение объекта: посчитай свою сумму, посчитай когда тебя отгрузили, посчитай ещё что-то такое.
Соответственно, программу можно разбить на блоки гораздо логичнее. Это означает, что можно написать гораздо большую программу, не теряя управляемости и возможности поддерживать ее. Под «поддерживать» подразумевается вносить изменения, различные исправления и улучшения.
Объектно-ориентированный парадигма на сегодняшний момент является фактически ультимативной. Она, с одной стороны, достаточно простая и понятная. Я вам рассказал основное об этой парадигме за несколько минут. С другой же стороны — она очень мощная, на ней можно писать огромные программы, очень сложный код.
Если парадигма легкая для понимания — в ней легче находить ошибки. А чем легче находить ошибки, тем меньше их будет в коде. Меньше ошибок = более надежная программа. Поэтому на сегодняшний момент объектно-ориентированная парадигма является золотой серединой между простотой и надежностью.
Конечно же, программирование на этом не остановилось. Объект-ориентированная парадигма возникла в конце прошлого века и до сих пор очень активно используется. Но существуют и другие: функциональные парадигмы, аспектно-ориентированные парадигмы и еще куча других вариантов. Но о них мы сейчас говорить не будем. Разбираться с ними сложно, поэтому оставим их более опытным программистам.
Ниши, для которых ООП не подходит
Как в любом направлении в ООП есть свои преимущества и недостатки. Например ООП не очень подходит для работы с потоковыми данными. Т.е. когда у вас нет объектов в предметной области, а есть поток данных. Натянуть ООП на такие задачи очень сложно. Для этого как раз прекрасно подходит функциональная парадигма. Поэтому большинство компаний, которые занимаются стриминговыми сервисами, типа Netflix и Megogo, используют именно функциональную парадигму для того, чтобы обрабатывать большие потоки данных. Но подавляющее большинство ниш, в которых нет потоков данных, а есть вполне себе реальные объекты, с которыми мы взаимодействуем, используют ООП.
Важное отступление. Если вы тот самый человек, который сейчас выбирает курс по обучению программированию, подумайте над тем, что в этом курсе вам собираются дать. Я рассказал вам фактически все, что вы должны знать про саму парадигму ООП. Да, еще хорошо знать три принципа ООП (наследование, полиморфизм и инкапсуляция), но дальше углубляться не обязательно. При этом у многих курсов раздел ООП занимает огромный блок, чуть ли не на месяцы занятий. С моей точки зрения всё ООП нужно осваивать исключительно на реальных задачах. А теории вам достаточно и той, что я дал. Дальше просто берете задачу и делаете ее, начинайте писать код. Так что как следует присматривайтесь к тем курсам, которые изучаете. Возможно ООП звучит сложно и поэтому многие курсы на этом играют.
Вообще ООП такая штука, что ее easy to learn, hard to master. Очень легко понять, но тяжело стать реально крутым мастером. Стать мастером ООП вы сможете только поработав программистом, разберавшись с патернами и другими сложными вещами. А вот основы вы уже получили.
Всегда ваш Сергей Немчинский
Задавайте свои вопросы по ООП в комментариях
Добавить комментарий