Что такое объектно-ориентированное программирование (ООП)?

Категория: Что такое?

– Автор: Игорь (Администратор)

Пожалуй, одним из самых распространенных подходов к созданию программ является объектно-ориентированное программирование. Собственно, о том, что представляет собой этот подход, каковы его базовые элементы и принципы, каковы плюсы и минусы, и пойдёт речь в данном обзоре.

Объектно-ориентированное программирование (ООП) это

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

ООП появилось из-за того, что программы становились сложнее и требовался какой-то более или менее внятный подход к структурированию данных и методов. Суть ведь в том, что когда у вас десяток отдельных функций и несколько разных переменных, то добавить ещё что-либо достаточно просто. А вот когда данных и методов становится много, то такой подход приводит к потере кучи времени и сил.

Если приводить пример из жизни, то отчасти подобный подход можно сравнить с разными типами сборки мебели. Существует мебель, которую необходимо собирать из кучи отдельных маленьких деталек, и существует модульная мебель, которая собирается из отдельных модулей. Когда речь о небольшой мебели, то разницы особой нет, как в плане сборки, так и в плане ремонта отдельных частей. А вот когда вам нужно собрать нечто большое, то существенно проще это делать с разными отдельными модулями. В такой ситуации если какой-то модуль портится, то его всегда можно быстро заменить или отремонтировать, а потом обратно поставить. Цельную же мебель пришлось бы вначале долго разбирать, чинить нужные детали, а потом обратно собирать.

Примеры языков с поддержкой ООП: C++, C#, Java, PHP, Ruby, Go, Python.

Объектно-ориентированное программирование: базовые элементы

В объектно-ориентированном программировании выделяют 4 базовых элемента:

1. Объект. Некоторая часть кода, которая описывает элемент с его данными и доступными методами. Например, объект автомобиль подразумевает определённые характеристики, такие как количество топлива, мощность, количество мест и т.д., а так же набор различных доступных действий, таких как ехать, тормозить, поворачивать и т.д.

2. Атрибут. Это, собственно, характеристики объекта (его данные). Кстати, стоит отметить, что в качестве данных может выступать и другой объект. Например, внутри объекта автомобиль может быть несколько объектов человек.

3. Метод. Это, собственно, методы, которые заданы внутри объекта. Методы позволяют выполнять некие действия с данными или взаимодействовать с другими объектами.

4. Класс. Это абстрактная форма описания объекта. По сути, шаблон того, как необходимо создавать объекты (какие атрибуты и методы должны быть). Тот же пример с автомобилем. Вначале создаётся описание шаблона, т.е. класс, а потом уже по этому шаблону создаются отдельные объекты (автомобили).

Основные принципы ООП

Существует 3 основных принципа ООП, рассмотрим каждый из них более подробно.

Инкапсуляция

Принцип инкапсуляции подразумевает, что информация, необходимая для функционирования объекта, должна храниться внутри этого объекта. При чём речь идёт как о данных, так и о методах. Изменения же данных должны выполняться через публичные методы объекта, т.е. те, которые могут вызывать другие объекты. Стоит отметить, что у объекта также могут быть публичные атрибуты, которые доступны для модификации и без методов.

Основная суть этого принципа в том, что объект должен быть полноценным элементом. Так же это касается и вопросов безопасности данных. Например, если объект может только сам менять свои характеристики, то это даёт уверенность в том, что данные не будут случайно повреждены другим объектом. Не говоря уже о том, что такой подход позволяет выстраивать взаимосвязи между объектами таким образом, что бы в этих связях можно было бы разобраться. Утрированный пример, тот же автомобиль, если на его скорость может влиять какой-то другой объект или несколько не через публичные методы, то это легко может приводить к ошибкам из-за случайных действий в других объектах. Кроме того, в такой ситуации найти проблемное место было бы существенно сложнее.

Наследование

Принцип наследования подразумевает, что классы могут наследовать атрибуты и методы других классов. Простой пример для понимания. Скажем, существует несколько разных видов автомобилей: гоночные, обычные, грузовые и т.д. Хоть эти автомобили и отличаются в ряде моментов, но всё же у них существуют какие-то общие характеристики и методы. В частности, у каждого авто существует параметр мощность двигателя и метод "ехать".

Соответственно, чтобы не писать в каждом классе одни и те же атрибуты и методы, можно создать общий класс Авто с базовым набором атрибутов и методов. А потом уже создавать классы, которые будут наследовать этот класс и расширять его возможности. Например, класс Грузовик наследует класс Авто. Это означает, что у класса Грузовик становятся доступными базовые атрибуты и методы класса Авто. Т.е. ничего не нужно писать повторно. И остаётся только в классе Грузовик дописать его уникальные атрибуты и методы. Например, метод "Загрузить вещи в кузов". У обычного автомобиля это может быть метод "Загрузить вещи в багажник".

Примечание: В принципе, метод "Загрузить вещи" может быть в базовом классе, но это же пример.

Наследование также позволяет упростить процесс добавления или корректирования наборов атрибутов и методов. Скажем, добавили в общий класс Авто метод "Бибикать" с атрибутом "Мелодия" и сразу у классов, которые наследуют класс Авто, появятся эти метод и атрибут.

Не сложно догадаться, что такой подход позволяет существенно упростить написание кода.

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

Полиморфизм

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

Звучит сложновато, но сейчас рассмотрим более простым языком. Абстрактный пример. Допустим, существует класс Корзина, в который можно складывать товары. Существует базовый класс Товар с методами "Списать товар со склада" и "Вернуть товар в склад". Методы применяются следующим образом. Когда пользователь добавляет товар в Корзину, то объект Корзина вычитает товар со склада вызовом метода "Списать товар со склада". Когда пользователь удаляет товар из Корзины, то объект Корзина возвращает товар в склад вызовом метода "Вернуть товар в склад".

Только вот нюанс в том, что существует несколько подклассов класса Товар, у которых отличается вариант списания и возврата товара. Скажем, классы РассыпчатыйТовар, ОбычныйТовар и ЖидкийТовар. В каждом из этих классов переопределены методы "Списать товар со склада" и "Вернуть товар в склад". Потому что процесс списания и возврата этих товаров отличается. Абстрактно, жидкий товар нельзя просто поставить на полку, как обычный товар, жидкость необходимо обратно выливать в общий резервуар.

Так вот, полиморфизм в данном случае состоит в том, что объект класса Корзина может вызывать базовые методы "Списать товар со склада" и "Вернуть товар в склад" класса Товар, обращаясь к добавленным объектам подклассов, и будут вызываться не базовые функция класса Товар, а переопределённые. Например, добавили ЖидкийТовар. Объект Корзина обращается к этому объекту как к объекту классу Товар, но вызывается не метод "Списать товар со склада" базового класса, а тот, который был переопределён в ЖидкомТоваре. Аналогичное действие происходит при удалении товара из объекта Корзины, только метод вызывается другой.

Иными словами, преимуществом полиморфизма является то, что он позволяет снижать сложность программ. Как это видно из примера с корзиной и товарами. Чтобы добавить или удалить товары из корзины не приходится создавать массу кода под разные подтипы общего класса Товар. Объекту класса Корзина, в принципе, не нужно знать как реализованы методы в подклассах, он вызывает методы исходного интерфейса, т.е. класса Товар.

Примечание: Вообще, полиморфизм это достаточно сложный вопрос и его реализация может сильно отличаться в разных языках. Но это отдельная большая тема.

Плюсы и минусы ООП

Теперь, рассмотрим плюсы и минусы объектно-ориентированного подхода программирования.

Плюсы ООП

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

2. Возможность повторного использования кода. Если код написан грамотно, то немалую часть классов можно переносить из программы в программу простым копированием. И это существенно упрощает процесс создания приложений. Скажем, написали когда-то код для построения формочек, а потом переносите от сайта к сайту, только дополняя стили и иногда корректируя под специфические нужды.

3. Проще разделять задачи. Сам подход ООП подразумевает, что каждый класс это решение какой-то отдельной задачи с какими-то определёнными входными и выходными параметрами. Поэтому и задачи проще разделять.

4. Читаемость кода. Когда код структурирован, а не разбит на множественно отдельных элементов с данными и тысячами функций, то код естественным образом становится более удобочитаемым. Скажем, тот же пример с человеком и автомобилем. Если вам нужно что-то посмотреть в методе автомобиля, то вам достаточно открыть соответствующий класс.

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

Минусы ООП

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

2. Требуется больше ресурсов. Объекты банально потребляют больше оперативной памяти.

3. Нужно уметь создавать классы по необходимости. Самый простой пример. Допустим, у вас есть 10 функций, которые что-то делают с текстом (обрезают по длине, заменяют разные символы и т.д.). Можно создать 1 класс с названием в стиле TextUtils (текстовые инструменты), а можно создать 10 отдельных классов для каждой функции. Не сложно догадаться, что чем больше будет код программы, тем больше будет сказываться разница этих двух подходов. Утрируя, что проще, разобраться в коде, где порядка 100 классов или где 1000? Так же это относится и к обратной ситуации, когда вместо того, чтобы разбить задачу на подзадачи, создаётся 1 огромный класс.

Также вам могут быть интересны обзоры:

1. Что такое Алгоритм?

2. Синтаксис (языки программирования): что это такое?

3. Сочетание функциональности и интерфейса

4. Оценка интерфейса или о чем говорит внешний вид

5. Универсальное или уникальное решение: что лучше?

Понравилась заметка? Тогда время подписываться в социальных сетях и делать репосты!