Для человека, не занимающегося разработкой в ИТ-бизнесе, очень важно знать основы каждой работы. Дизайнеру хорошо знать, что такое письмо, хороший писатель должен знать дизайн, и каждый должен знать основы разработки.
Мы говорим о теоретических знаниях, достаточных для того, чтобы ценить труд друг друга, и, по крайней мере, говорить на одном языке, когда дело касается разрешения споров. В этом разделе мы рассмотрим конкретную, но общую тему объектно-ориентированного программирования и его значение для нетехнических специалистов.
Процедурное программирование
Компьютеры хранят огромные объемы данных, доступные в считанные секунды. Использование памяти для хранения данных - основная идея традиционной или процедурной разработки. Основное внимание уделяется процедурам и функциям. Процедура - это последовательность инструкций. Функция похожа на небольшую сборочную линию, которая получает входные данные, что-то с ними делает и возвращает некоторые данные результата. Один вход имеет один выход:
Например, функция проверки электронной почты. Он получает некоторый ввод пользователя, проверяет его на соответствие некоторым правилам и создает вывод, в котором говорится, является ли это электронное письмо правильным или неправильным (истинным или ложным).
Процедуры полезны, когда нужно упаковать множество команд в одну. Вы можете проверить электронную почту, выполнив одну команду, чтобы увидеть, соответствует ли ввод регулярным выражениям или нескольким командам, таким как проверка словаря, каталогов спама и существующих баз электронной почты. Функция может упаковывать множество команд и действий и вызывать их все одним движением.
Несогласованность именования с процедурами и функциями. Из-за вмешательства в функциональные языки процедуры превратились в функции, а функции с должной сложностью - в процедуры. Все это сущности процедурного программирования, поэтому это не имеет значения, потому что «фон, стоящий за этими названиями, был давно смыт». - jpalecek на Stack Overflow.
Что плохого в процедурном программировании
Процедурное программирование отлично работает в простых программах, где большинство задач можно решить с помощью нескольких функций. Функции могут быть вложенными, взаимодействовать друг с другом и обрабатывать данные от одной функции к другой.
Если вы создаете функцию «Регистрация пользователя», внутри нее вам нужно проверить электронную почту, которую они отправляют. Вы вызываете функцию «Проверить электронную почту» внутри функции «Зарегистрировать пользователя» и, в зависимости от вывода функции, вы либо регистрируете пользователя, либо указываете ошибку и просите их исправить ее. Может быть несколько мест, где используется одна и та же функция. Это заставляет функции переплетаться.
Затем появляется менеджер по продукту и говорит: «Мы должны сообщить пользователю, в чем именно заключается ошибка при вводе электронной почты». Теперь нам нужно, чтобы функция выполняла не только true-false, но и код ошибки. Если в адресе электронной почты есть опечатка, это код 101, предупреждение каталога спама - код 102 и т. Д.
Это не сложно. Вы просто попадаете внутрь функции и меняете ее поведение: вместо вывода «истина / ложь» она возвращает код ошибки или, если ошибки нет, говорит «ОК». И здесь код ломается. Все места, где ожидаемый ответ был «правда / ложь», теперь получают «ОК» и не понимают его.
Чтобы это исправить, нам необходимо:
- Перепишите все функции, чтобы они распознавали новые ответы.
- Повторите проверку, чтобы она оставалась совместимой со старыми функциями, но при необходимости могла отправлять ответ.
- Напишите новую программу проверки для новых ответов и используйте другую программу проверки для старых функций.
Все это можно сделать за час работы. Но представьте, что есть сотни функций, и они меняются каждый день. Каждое изменение приводит к более сложному поведению и результату функции. Каждое изменение в одном месте влияет на три других места. У вас будут десятки клонированных функций, и в конце концов вы потеряете над ними контроль.
Это то, что они называют «спагетти-кодом», и поэтому было создано объектно-ориентированное программирование.
Объектно-ориентированное программирование
Судя по названию, ООП - это некие объекты, которые запускают весь процесс программирования. Это имеет большой смысл с точки зрения реального мира, где все является объектом с набором свойств, взаимодействующих друг с другом и изменяющихся из-за этого взаимодействия. Это естественное видение было воссоздано в программировании.
Нам пришлось абстрагироваться от принципов того, как компьютеры хранят и обрабатывают информацию, и научиться создавать «виртуальные миры» с распределенными свойствами. Это, однако, упростило программирование и сделало его более продуктивным для задач, число которых постоянно росло.
Команда разработчиков создает видеоигру. Игра - это система персонажей и окружения с множеством объектов. Каждый персонаж, оружие, дерево, дом - это цифровой объект, содержащий свои свойства и действия, которые изменяют сам объект, а также другие объекты.
Каждый разработчик может работать над своей конкретной группой объектов. Им достаточно договориться о том, как интерфейсы объектов будут взаимодействовать. Если вы строите газон, вам не нужно знать, как корова, поедающая траву, набирает вес. Все, что вам нужно знать, это когда корова касается хитбокса травы, она уменьшает ее количество.
Основное различие между традиционной программой и объектно-ориентированной программой состоит в том, что первое касается логики и последовательности действий для достижения цели. Второй - это программа как система взаимодействующих объектов.
ООП упрощает код. Объект - это не космическое существо. Это все еще набор данных и функций, как в процедурной разработке. Думайте об этом, как о том, что вы кладете часть программы в коробку и закрываете ее. Эта запечатанная коробка - объект.
Разработчики согласились вызывать данные внутри объекта свойства, а функции - методы. По сути, это традиционные переменные и функции. Объект похож на одну из кухонных принадлежностей. Чайник кипятит воду, плита нагревается, блендер смешивает и т. Д. Внутри каждого устройства есть множество различных частей, таких как двигатели, предохранители, провода, микросхемы и модули, но мы не думаем о них, когда используем устройство. Он просто делает то, что мы от него ожидаем. Все устройства, работающие вместе, несут ответственность за ваш обед.
Инкапсуляция, абстракция, наследование, полиморфизм
Это ключевые концепции ООП. Они позволяют разработчикам создавать рабочие методы и переменные, а затем повторно использовать их.
Инкапсуляция означает, что объект независим. Каждый объект настроен таким образом, что необходимые ему данные живут внутри этого объекта, а не где-то еще в программе. Например, объект «пользователь» содержит все данные о нем: их имя, адрес электронной почты и все остальное. Также в нем есть методы «проверить электронную почту» или «подписаться на рассылку новостей».
Абстракция означает, что у объекта есть интерфейс. У объекта есть методы и свойства, которые мы можем вызывать извне. Блендер имеет все сложные механизмы внутри, но только одну кнопку снаружи. Эта кнопка - абстрактный интерфейс.
В программе мы можем сказать «удалить пользователя». На языке ООП это «user.delete ()», что означает, что мы обращаемся к объекту «пользователь» и вызываем метод «удалить». Самое крутое в этом то, что нас не волнует, как именно удаляют пользователя. Нам не нужно думать об этом при звонке.
Например, если два разработчика создают магазин, один пишет модуль заказа, а другой - отгрузку. В объекте «заказ» есть метод «отменить». Другой должен иметь возможность отменить заказ на экране доставки. Поэтому они просто пишут «order.cancel ()». Неважно, как другой разработчик собирается реализовать отмену, какие типы уведомлений они будут отправлять, что будет записано в базу данных и т. Д.
Наследование - это возможность делать копии. Это означает, что разработчики могут создавать множество объектов по образу и подобию другого объекта. Таким образом, им не нужно копировать и вставлять код несколько раз, а писать его один раз и повторно использовать в будущем.
Например, идеальный объект под названием «Пользователь» хранит всю возможную информацию о том, что с ним может случиться. Свойства могут быть имя, возраст, адрес электронной почты, кредитная карта. Методами могут быть «Сделать скидку», «Проверить заказ», «Найти заказы», «Связаться». На основе этого вы создаете настоящего пользователя, который будет обладать всеми свойствами и методами идеального пользователя с дополнительными, если это необходимо.
Разработчики называют эти совершенные объекты классами.
Полиморфизм - это общий язык. В ООП очень важно, чтобы объекты говорили на одном языке. Если у разных объектов есть метод «Удалить», он должен делать именно это и везде иметь одинаковую форму. Это не может быть «Удалить» для одного объекта и «Удалить» для другого.
При этом внутри объекта методы могут быть реализованы различными способами. Например, когда удаление элемента означает отображение предупреждения и пометку элемента как удаленного. Удаление пользователя означает отмену его покупок, отказ от подписки на него из списка и архивирование истории их заказов. Это разные события, но для разработчика это не имеет значения. Для разработчика это просто метод Delete (), и они ему доверяют.
При таком подходе разработчики могут создавать модули независимо от других модулей. Главное - подробно рассказать о том, как эти модули будут взаимодействовать. При таком подходе они могут улучшить работу одного модуля, не затрагивая другие. Сама программа не заботится о том, что находится внутри каждого блока, если правила, по которым она работает, остаются прежними.
Плюсы и минусы ООП
Плюсов намного больше, и поэтому подавляющее большинство современных разработчиков используют объектно-ориентированное программирование.
- Визуально код становится чище и читабельнее. Когда все является объектом с его четким набором правил, мы можем выяснить, какой объект что делает и из чего он состоит.
- Менее похожий код. В традиционном программировании одна функция считает повторяющиеся символы в одномерном массиве, а другая - в двумерном, большая часть их кода будет идентична. В ООП это решается путем наследования.
- Для написания сложных программ требуется меньше времени. Каждую большую программу можно разделить на несколько блоков, заполнить их минимально жизнеспособным, а затем постепенно насыщать их большей функциональностью.
- Скорость разработки увеличивается. Вначале вы можете создать необходимые компоненты внутри программы, чтобы получить минимально жизнеспособный прототип.
Теперь о минусах:
- Трудно понять и начать. Подход ООП сложнее процедурного программирования; вы должны иметь много теоретических знаний еще до того, как дойдете до своей первой строчки кода.
- Требуется больше памяти. В ООП объекты состоят из данных, интерфейсов, методов и т. Д. Для этого требуется больше дискового пространства, чем просто переменная.
- Иногда производительность кода может быть снижена. Из-за такого подхода некоторые вещи можно реализовать сложнее. Вот почему программа ООП может работать медленнее, чем процедурная. Однако с современными процессорами это никого не слишком беспокоит.
Эта статья основана на материалах обучения из Код и Лаборатория линуксоида.
