Принципы ооп. Основы объектно-ориентированного программирования 2 объектно ориентированное программирование

Концепция объектно-ориентированного программирования (ООП) появилась более сорока лет назад, как развитие идей процедурного программирования. Идеология процедурного программирования, на мой взгляд, ничего особенного собой не представляет: все программы представлены набором процедур и функций, в то время как сами процедуры и функции – это последовательности операторов, выполняя которые модифицирует значения переменных в памяти. Основная программа в процедурном программировании также является процедурой (функцией), в теле которой могут быть вызовы других процедур и функций – подпрограмм. Суть процедурного программирования проста: данные отдельно, поведение отдельно. То (какие конструкции в него входят), я постарался собрать в отдельном разделе. Разделение кода на подпрограммы, во-первых, позволяет , а во-вторых, .

Идеология объектно-ориентированного программирования, как следует из самого названия, строится вокруг понятия объект. Объект объединяет в себе и данные и поведение. Объект – это любая сущность, с которой имеет дело программа, а именно: объекты предметной области, моделируемые программой; ресурсы операционной системы; сетевые протоколы и многое другое. По сути, объект – это та же , но дополненная процедурами и функциями, управляющими элементами этой структуры. К примеру, в процедурном языке программирования отдельно была бы создана переменная для хранения имени файла и отдельно – для хранения его дескриптора (уникальный идентификатор ресурса в операционной системе), а также ряд процедур работы с файлом: открыть файл, прочитать данные из файла и закрыть файл. Все бы эти процедуры, помимо обычных параметров и переменных для хранения результата, обязаны были бы принимать тот самый дескриптор, чтобы понять, о каком именно файле идет речь. В объектно-ориентированном языке для этих же целей был бы описан объект-файл, который также бы хранил внутри себя имя и дескриптор и предоставлял бы пользователю процедуры для открытия, чтения и закрытия себя самого (файла, ассоциированного с конкретным объектом). Разница была бы в том, что дескриптор был бы скрыт от остальной части программы, создавался бы в коде процедуры открытия файла и использовался бы неявно только самим объектом. Таким образом, пользователю объекта (программному коду внешней по отношению к объекту программы) не нужно было бы передавать дескриптор каждый раз в параметрах процедур. Объект – это комплект данных и методов работы с этими данными, часть из которых может быть скрыта от окружающего его мира, к которой и относятся детали реализации. Более подробно о терминологии объектно-ориентированного программирования будет рассказано далее.

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

Терминология объектно-ориентированного программирования

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

Класс – тип данных, описывающий структуру и поведение объектов.

Объект – экземпляр класса.

Поле – элемент данных класса: переменная элементарного типа, структура или другой класс, являющийся частью класса.

Состояние объекта – набор текущих значений полей объекта.

Метод – процедура или функция, выполняющаяся в контексте объекта, для которого она вызывается. Методы могут изменять состояние текущего объекта или состояния объектов, передаваемых им в качества параметров.

Свойство – специальный вид методов, предназначенный для модификации отдельных полей объекта. Имена свойств обычно совпадают с именами соответствующих полей. Внешне работа со свойствами выглядит точно так же, как работа с полями структуры или класса, но на самом деле перед тем, как вернуть или присвоить новое значение полю может быть выполнен программный код, осуществляющий разного рода проверки, к примеру, проверку на допустимость нового значения.

Член класса – поля, методы и свойства класса.

Модификатор доступа – дополнительная характеристика членов класса, определяющая, имеется ли к ним доступ из внешней программы, или же они используются исключительно в границах класса и скрыты от окружающего мира. Модификаторы доступа разделяют все элементы класса на детали реализации и открытый или частично открытый интерфейс.

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

Деструктор – специальный метод, вызываемый средой исполнения программы в момент, когда объект удаляется из оперативной памяти. Деструктор используется в тех случаях, когда в состав класса входят ресурсы, требующие явного освобождения (файлы, соединения с базами данных, сетевые соединения и т.п.)

Интерфейс – набор методов и свойств объекта, находящихся в открытом доступе и призванных решать определенный круг задач, к примеру, интерфейс формирования графического представления объекта на экране или интерфейс сохранения состояния объекта в файле или базе данных.

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

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

Преимущества объектно-ориентированного программирования

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

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

Наследование . Краеугольный камень ООП. В объектно-ориентированном программировании есть возможность наследовать структуру и поведение класса от другого класса. Класс, от которого наследуют, называется базовым или суперклассом, а класс, который получается вследствие наследования – производным или просто потомком. Любой класс может выступать как в роли суперкласса, так и в роли потомка. Связи наследования классов образуют иерархию классов. Множественным наследованием называют определение производного класса сразу от нескольких суперклассов. Не все объектно-ориентированные языки программирования поддерживают множественное наследование. Наследование – это эффективный способ выделения многократно используемых фрагментов кода, но у него есть и минусы, о которых будет рассказано далее.

Абстрагирование . Возможность объединять классы в отдельные группы, выделяя общие, значимые для них всех характеристики (общие поля и общее поведение). Собственно, абстрагирование и есть следствие наследования: базовые классы не всегда имеют свою проекцию на объекты реального мира, а создаются исключительно с целью выделить общие черты целой группы объектов. К примеру, объект мебель – это базовое понятие для стола, стула и дивана, всех их объединяет то, что это движимое имущество, часть интерьера помещений, и они могут быть выполнены для дома или офиса, а также относиться к “эконом” или “премиум” классу. В ООП есть для этого отдельное понятие абстрактный класс – класс, объекты которого создавать запрещено, но можно использовать в качестве базового класса. Наследование и абстрагирование позволяют описывать структуры данных программы и связи между ними точно так же, как выглядят соответствующие им объекты в рассматриваемой .

Пример диаграммы классов, построенной путем абстрагирования, в ходе анализа видов существующих транспортных средств приведен на следующем рисунке. На верхних уровнях иерархии наследования находятся абстрактные классы, объединяющие транспортные средства по наиболее значимым характеристикам.

Диаграмма классов или иерархия наследования "Транспортные средства". Белые квадраты обозначают абстрактные классы.

Полиморфизм . Еще одно свойство, которое является следствием наследования. Дело в том, что объектно-ориентированные языки программирования позволяют работать с набором объектов из одной иерархии точно так же, как если бы все они были объектами их базового класса. Если вернуться к примеру про мебель, то можно предположить, что в контексте создания информационной системы для мебельного магазина в базовый класс для всех видов мебели разумно добавить общий для всех метод “показать характеристики”. При распечатке характеристик всех видов товара программа бы без разбору для всех объектов вызывала бы этот метод, а каждый конкретный объект уже сам бы решал, какую информацию ему предоставлять. Как это реализуется: Во-первых, в базовом классе определяют общий для всех метод с общим для всех поведением. В случае с нашим примером это будет метод, печатающий общие для любых типов мебели параметры. Во-вторых, в каждом производном классе, где это необходимо, переопределяют базовый метод (добавляют метод с тем же именем), где расширяют базовое поведение своим, например, выводят характеристики, свойственные только конкретному виду мебельной продукции. Метод в базовом классе иногда вообще не обязан содержать какой-либо код, а необходим только для того, чтобы определить имя и набор параметров – сигнатуру метода. Такие методы называют абстрактными методами, а классы, их содержащие, автоматически становятся абстрактными классами. Итак, полиморфизм – это возможность единообразного общения с объектами разных классов через определенный интерфейс. Идеология полиморфизма гласит, что для общения с объектом вам не нужно знать его тип, а нужно знать, какой интерфейс он поддерживает.

Интерфейс . В некоторых языках программирования (C#, Java) понятие интерфейса выделено явно - это не только открытые методы и свойства самого класса. Такие языки, как правило, не поддерживают множественного наследования и компенсируют это тем, что любой объект может иметь один базовый объект и реализовывать любое количество интерфейсов. Интерфейс в их интерпретации – это подобие абстрактного класса, содержащего только описание (сигнатуру) открытых методов и свойств. Реализация интерфейса ложится на плечи каждого класса, который собирается его поддерживать. Один и тот же интерфейс могут реализовывать классы абсолютно разных иерархий, что расширяет возможности полиморфизма. К примеру, интерфейс “сохранение/восстановление информации в базе данных” могли бы реализовывать как классы иерархии “мебель”, так и классы, связанные с оформлением заказов на изготовление мебели, а при нажатии на кнопку “сохранить” программа бы прошлась по всем объектами, запросила бы у них этот интерфейс и вызвала бы соответствующий метод.

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

Некоторые элементы современного объектно-ориентированного программирования

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

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

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

Исключения . Еще один специальный вид объектов, поддерживаемый встроенным в конкретный язык программирования механизмом обработки ошибок и исключительных ситуаций. Исключения, помимо кода ошибки, содержат ее описание, возможные причины возникновения и стек вызовов методов, имевший место до момента возникновения исключения в программе.

Недостатки объектно-ориентированного программирования

Про то, что популярность объектно-ориентированного подхода к огромна я уже сказал. Про то, что тех, кто стремится расширить эту парадигму довольно много, я тоже уже отметил. Но есть еще один способ выделиться среди огромного сообщества специалистов в информационных технологиях – это заявить, что ООП себя не оправдало, что это не панацея, а, скорее, плацебо. Есть среди этих людей действительно специалисты очень высокого класса, такие как , Александр Степанов, Эдсгер Дейкстра и другие, и их мнение заслуживает внимания, но есть и те, про которых говорят, что “плохому танцору всегда что-то мешает”. Вот они, наиболее очевидные недостатки ООП, на которые указывают специалисты:

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

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

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

Всем привет.

Неделя статей на хабре посвященная ООП. Последняя статья вызвала у меня кучу эмоций и, к сожалению, очень плохих эмоций. Мне очень не понравилась статья. Почему? Потому что в ней передаются какие-то отрицательные эмоции об использовании ООП. Эмоции вызваны лишь тем, что человек не до конца понимает всю силу ООП и хочет убедить всех в том что ООП зло. Самое печальное что люди начинают прислушиваться и кидаться ужасными доводами, не имеющими ничего общего с действительностью. Я думаю что студентам такие статьи противопоказаны больше чем GoF, которых я бы давал как можно раньше. :)

Начнем.

Что такое ООП. ООП - это и ОО программирование и проектирование. Одно без другого бессмысленно чуть более чем полностью. Создано ООП для проектирования/программирования программных продуктов. Не для моделирования процессов. Не для проектирования протоколов, а именно для программных продуктов, для их реализации. Для упрощения системы, которая будет реализовывать протокол или бизнес-процесс или что-то еще.

Когда вы начинаете использовать ООП, первое что вы должны сделать - это начать использовать объектное мышление. Я уже когда-то говорил что это самая большая проблема ООП, научиться мыслить объектно очень сложно. И очень важно учиться это делать как можно раньше (GoF с аналогиями типа мост, конструктор, фасад очень в этом помогут). Используя объектное мышление, вы легко сможете проектировать сложные системы Используя объектное мышление вы легко можете решить любую задачу (очень важно что любую задачу проектирования/программирования, если ее в принципе можно решить абсолютно любую) оперируя объектами и взаимодействием между ними. Т.е. ООП без объектного мышления не позволит вам начать использовать всю силу и мощь ООП.

Пойдем дальше. Итак, нам важно мыслить объектно, для того, что бы найти нужные нам абстракции объектов для решения наших задач. Если аналогии и абстракции выбраны удачно, то мы видим очень четкую картину которая позволяет нам быстро разобраться в том, что же происходит в системе. И вот тут мы начинаем вспоминать про наследование и полиморфизм. Эти два инструмента нужны для удобного масштабирования системы без дублирования кода. Но сила этих механизмов зависит от того насколько удачные абстракции и аналогии вы выбрали. Если ваше объектное мышление не позволяет вам сформировать удобную декомпозицию объектов, то наследование и полиморфизм вам не помогут. Т.е. наследование и полиморфизм это ничто иное как инструменты, которые позволяют решить проблему масштабирования системы.

Как же эти инструменты работают? Да проще пареной репы, потому что это все основано на привычных нам вещах. Люблю простые примеры из жизни:

1. Наследование. Есть пекарь. Есть печь электрическая и газовая. Ваша задача смоделировать процесс приготовления пищи пекарем в каждой из печи. Решая задачу в лоб, у нас будет много дублирования кода из-за того, что сам процесс передачи пищи в печь и сама работа с печами идентичны для обеих печей. Но если мы включаем объектное мышление, и вспоминаем про инструмент наследование, то получаем примерно следующее (диаграмму лень рисовать, сорри):
Есть печь (абстрактная печь). У нее есть поведение - включить, выключить, увеличить или уменьшить температуру, положить чего-то, достать чего-то и состояние - температура в печи, включена или выключена. Это отличный пример абстрактного объекта в котором соблюдены принципы инкапсуляции (при реализации я их обязательно буду соблюдать). И есть пекарь, конкретный такой пекарь Иван. Он умеет работать с абстрактной печью. Т.е. смотреть температуру, включать выключать и т.д. вы поняли. Сила наследования в том, что нам не придется переписывать нашего Ивана для каждой из печей, будь то электро или газовая печь. Я думаю всем ясно почему? Получается что инструмент применен правильно.
2. Полиморфизм. Печи ведь по-разному работают. Газовая потребляет газ, электро печь - электричество. Используя полиморфизм мы легко меняем поведение в наследниках абстрактной печи.
3. Инкапсуляция. Основная фишка инкапсуляции в том, что я не должен знать, что происходит внутри моей печи. Допустим, я вызываю не метод включить печь, а меняю ее свойство включена на значение true. Что произойдет в этот момент? Если принцип инкапсуляции не соблюден, то я буду вынужден печи сказать начинай потреблять горючее, т.к. я тебя включил. Т.е. пекарь знает, что печь потребляет горючее, знает, как печь работает. Или, например, мы не можем установить температуру печи ниже или выше определенного уровня. Если не соблюдать принцип инкапсуляции, то мы должны будем говорить печи проверь-ка текущую температуру, пойдет те такая? Т.е. пекарь опять слишком много знает о печи. Геттеры и сеттеры это средства языка, которые помогут нам легко реализовать отслеживание изменений состояния. Все. Если геттеры и сеттеры пустые, значит так надо на моем уровне абстракции. Геттеры и сеттеры - не могут мешать реализации инкапсуляции, криво реализовать инкапсуляцию может проектировщик/программист.

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

Еще стали добавлять абстракцию, как еще один столп ООП. Я думаю, что это скорее верно, но уж очень попахивает КЭПом.

Высказывания про типизацию меня тоже зацепили. Дело в том, что никаких проблем в том, с кем вы сейчас работаете из наследников нет. Если на текущем уровне абстракции вам важно именно использовать печь, то вам не важно какая она. Вы получаете печь? Вы решаете свои задачи? То то и оно… Почему вы считаете что это динамическая типизация мне не понятно. Вы хотели печь? Берите. Вам нужна электрическая? Ну извините, газовая вам уже не подойдет.

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

Отдельно про DTO. DTO - это паттерн. Он позволяет создать объект, который передаст информацию другому слою, другой системе, короче куда-то чего-то передаст. Почему он не может быть рассмотрен мною как объект для меня вообще загадка. Где противоречие то? Является контейнером только? Ну и что?? Это же объект в рамках рассмотренной мною объектной модели на заданном уровне абстракции, где DTO - объект и часть декомпозиции.

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

Еще говорят что некоторые вещи нельзя представить в виде объектов и их взаимодействия. Я уверен что это не так. Просто необходимо выбрать уровень абстракции верно. Будь то реализация протокола, слоя доступа к БД, подключения плагинов, менеджера задач, бизнес процесса, системы проектирования бизнес процессов т.е. все что угодно можно представить как объекты и их взаимодействие. Все можно реализовать как объекты и взаимодействие между ними. Хорошо это или плохо чаще всего зависит лишь от вашего умения мыслить объектно.

Резюмируя. Если вы не понимаете силу ООП, то скорее всего вам надо развивать объектное мышление.

P.S. В комментах к прошлой статье я явно много перегибал палку при обращении к некоторым людям. Приношу свои извинения.

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

Объекты в ООП — это объекты реального мира

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

Предположим что нам нужно разработать систему автоматизации банка. Эта система могла быть осуществлена следующим образом:

В операции снятия денег через банкомат участвуют 3 объекта : «клиент Иванов», «банкомат на Тверской» и «счет № 66579801», который открыт в данном банке для Иванова. Подойдя к банкомату и засунув свою карточку, объект «клиент Иванов» посылает банкомату сообщение «Начать работу». Получив такое сообщение, банкомат выводит на экран какую-нибудь информацию и запрашивает код доступа, т.е объект «банкомат на Тверской» посылает сообщение объекту «клиент Иванов» — «Сообщить идентификационный код». Если идентификация прошла успешно, «клиент Иванов» просит выдать ему 1000 рублей. Он посылает сообщение об этом банкомату, а тот в свою очередь объекту «счет № 66579801». Приняв это сообщение объект «счет № 66579801» проверяет есть ли у него 1000 рублей, и, если есть, пересылает разрешение на снятие денег, одновременно уменьшая свой баланс на соответствующую сумму. Банкомат передает деньги и на этом процедура заканчивается.

Объекты выполняют необходимые действия передавая друг другу сообщения.

Описание в виде объектов позволяет определить различные компоненты системы. Те же самые объекты — «счет № 66579801» и «клиент Иванов» — будут учавствовать в другой операции при которой клиент приходит в отделение банка для снятие или зачисления денег на свой счет.

Приведенная ситуация является ярким примером сущности понятия «объект в ООП «. Сложно дать четкое определение этому понятию, приведу цитату этого определения Ивара Якобсона:

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

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

абстракция понятия: объект — это модель какого-то понятия предметной области;
абстракция действия: объект объединяет набор операций для выполнения какой-либо функции;
абстракция виртуальной машины: объект объединяет операции, которые используются другими, более высокими уровнями абстракции;
случайная абстракция: объект объединяет не связанные между собой операции.

Состояние объекта в ООП

Каждый объект в ООП характеризуется своим состоянием. Состояние банковского счета — это сумма лежащих на нем денег. Состояние банкомата включает в себя состояние «включен» или «выключен», готов или не готов к принятию запроса, наличию денег в банкомате.

Состояние объекта характеризуется текущим значением его атрибутов . В нашем примере у счета есть атрибут -баланс. В простейшем случае он отражается числом — количеством рублей и копеек на счету. Операция снятия или зачисления на счет изменяет баланс и атрибут объекта «счет № 66579801». У объекта «банкомат на Тверской» есть несколько атрибутов. Количество денег в банкомате может характеризоваться числом. Состояние «включен» или «выключен» и состояние «готов или не готов к принятию запроса» — логическим значением.

Стоит заметить, что атрибутами объекта в ООП могут быть не только простейшие значения (число, логическое значение и т.д.), но и сложные величины или другие объекты. Например, наш банк для целей контроля будет хранить историю всех транзакций. Транзакция — это объект, который имеет атрибуты (характеристики) тип транзакции, сумма переведенных денег, место совершения и имена контрагентов этой операции. У объекта «счет № 66579801» появится новый атрибут — «история транзакций», который будет состоять из набора объектов-транзакций.

Идентификация объектов в ООП

Иногда нужно идентифицировать объекты в ООП, т.е., если имеются два объекта, как можно определить что эти объекты разные. Например, такая процедура очень важна для идентификации банковского счета (объект «счет № 66579801») клиента банка Иванова.

На самом деле существует два вопроса: равны ли два объекта или тождественны.

Обычно для идентификации применяются специальные атрибуты объектов — идентификаторы. Например, для объекта «счет № 66579801» идентификатором является его атрибут «номер счета», который является уникальным (соблюдается требование предметной области).

В свою очередь, зная идентификаторы объектов можно точно определить являются ли они тождественными или нет.

Интерфейс объекта в ООП

Важнейшей характеристикой объекта в ООП является описание того, как он может взаимодействовать с окружающим миром. Это описание называется интерфейсом объекта .

Объекты в ООП взаимодействуют между собой с помощью сообщений. Принимая сообщение, объект выполняет соответствующее действие. Эти действия обычно называются методами .

В нашем примере у объекта «счет № 66579801» есть следующие методы — «снять деньги со счета» и «положить деньги на счет». Эти два метода и составляют интерфейс объекта. У объекта «клиент Иванов» имеется метод «Сообщить свой код». А у объекта «банкомат на Тверской » есть методы «начать работу», «принять деньги», «выдать деньги».

У объекта «счет № 66579801» есть еще один атрибут «баланс». Является ли он частью интерфейса объекта? Интерфейс — это внешнее описание объекта. При разработке банковской системы и, в частности, объекта «счет», мы решаем вопрос: является ли баланс необходимой информацией для других объектов? Очевидно, что является. Тогда нам нужно ответить на еще один вопрос: что именно нужно другим объектам? Остаток денег на счете. В таком случае необходимо добавить еще один метод «сообщить остаток денег на счете» к объекту «счет» , и его интерфейс будет теперь состоять из трех методов.

Таким образом, атрибут баланс не является непосредственно частью интерфейса. Другие объекты могут обратиться к этому атрибуту только опосредственно, с помощью метода «сообщить остаток на счете» (тем самым они не могут непосредственно менять значение этого атрибута).

Наряду с методами и атрибутами, входящими в интерфейс и доступными другим объектам, у объекта могут быть атрибуты предназначенные для внутреннего использования (к ним может обращаться только сам объект). Например, у банкомата очень сложная внутренняя структура, т.е. он имеет огромное количество атрибутов. Но для банковской системы они не важны, и ни клиент, ни объект «счет» не могут к ним обратиться. Они не входят в интерфейс объекта «банкомат».

Время жизни объекта в ООП

В любой системе объекты создаются, функционируют и уничтожаются. В программировании существуют два способа уничтожения объектов:

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

Но в тоже время могут существовать объекты, для которых необходимо восстанавливать их предыдущее состояние при новом запуске программы. Для работы с такими объектами применяется метод сериализации , когда значения всех атрибутов записываются, и, при необходимости восстановления объекта, считываются. Схема данного метода представлена ниже.

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

Со временем жизни и идентификации объектов тесно связано еще одно понятие — понятие объектов первого и второго сорта или равноправия объектов в системе.
Объект считается самостоятельным или первого сорта, в том случае, если он обладает всеми признаками идентификации объектов, принятыми в данной объектной среде, и время его жизни не связано со временем жизни породившего его объекта.

Композиция объектов в ООП

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

В следующей статье будут рассмотрены классы в ООП, как способ описания структуры и поведения объектов.

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

Любая программа, написанная на языке ООП, отражает в своих данных состояние физических предметов либо абстрактных понятий – объектов программирования, для работы, с которыми она предназначена.

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

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

Описание множества однотипных объектов называется классом .
Объект – это структурированная переменная, содержащая всю информацию о некотором физическом предмете или реализуемом в программе понятии.

Класс – это описание множества объектов программирования (объектов) и выполняемых над ними действий.

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

Основные понятия объектно-ориентированного программирования

Любая функция в программе представляет собой метод для объекта некоторого класса.

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

Вся программа в таком виде представляет собой объект некоторого класса с единственным методом run (выполнить).

Программирование «от класса к классу» включает в себя ряд новых понятий. Основными понятиями ООП являются

инкапсуляция;
наследование;
полиморфизм.

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

Внутри объекта коды и данные могут быть закрытыми или открытыми.

Закрытые коды или данные доступны только для других частей того же самого объекта и, соответственно, недоступны для тех частей программы, которые существуют вне объекта.

Открытые коды и данные, напротив, доступны для всех частей программы, в том числе и для других частей того же самого объекта.

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

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

Иначе говоря, новый класс наследует как данные старого класса, так и методы их обработки.

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

Пример наследования – определение структуры, отдельный член которой является ранее определенной структурой.

Полиморфизм – это свойство, которое позволяет один и тот же идентификатор (одно и то же имя) использовать для решения двух и более схожих, но технически разных задач.

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

Будучи доступным в некоторой точке программы, объект, даже при отсутствии полной информации о его типе, всегда может корректно вызвать свойственные ему методы.
Полиморфная функция – это семейство функций с одним и тем же именем, но выполняющие различные действия в зависимости от условий вызова.

Например, нахождение абсолютной величины в языке Си требует трех разных функций с разными именами.

Из своего опыта могу сказать, что всегда считал что понимал ООП, что же тут такого то - полиморфизм, инкапсуляция и наследование, но вот когда дошло до дела, то туговато пришлось. Хочу разложить всё по полочкам чтобы никто не наступил на мои грабли в будущем:)

Шаг 1.

Немного теории:

Объектно-ориентированное программирование (в дальнейшем ООП) - парадигма программирования, в которой основными концепциями являются понятия объектов и классов.

В центре ООП находится понятие объекта.

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

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

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

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

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

Инкапсуляция - это свойство системы, позволяющее объединить данные и методы, работающие с ними в классе, и скрыть детали реализации от пользователя.

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

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

Шаг 2.

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

Инкапсуляция позволит скрыть детали реализации, и открыть только то что необходимо в последующем использовании. Другими словами инкапсуляция – это механизм контроля доступа.

Зачем же это нужно?

Думаю, вам бы не хотелось, чтобы кто-то, что-то изменял в написанной вами библиотеки.

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

Цель инкапсуляции – уйти от зависимости внешнего интерфейса класса (то, что могут использовать другие классы) от реализации. Чтобы малейшее изменение в классе не влекло за собой изменение внешнего поведения класса. Давайте рассмотрим, как ею пользоваться.

Существует 4 вида модификаторов доступа: public , protected , private и default .

Public – уровень предполагает доступ к компоненту с этим модификатором из экземпляра любого класса и любого пакета.

Protected – уровень предполагает доступ к компоненту с этим модификатором из экземпляров родного класса и классов-потомков, независимо от того, в каком пакете они находятся.

Default – уровень предполагает доступ к компоненту с этим модификатором из экземпляров любых классов, находящихся в одном пакете с этим классом.

Private – уровень предполагает доступ к компоненту с этим модификатором только из этого класса.

Public class Human { public String name; protected String surname; private int age; int birthdayYear; }

public String name; - имя, которое доступное из любого места в приложении.
protected String surname; - фамилия доступна из родного класса и потомков.
private int age; - возраст доступен только в рамках класса Human.
int birthdayYear; - хоть не указывается явный модификатор доступа, система понимает его как default, год рождения будет доступен всему пакету, в котором находится класс Human.

Для разных структурных элементов класса предусмотрена возможность применять только определенные уровни модификаторов доступа.

Для класса - только public и default.

Для атрибутов класса - все 4 вида.

Для конструкторов - все 4 вида.

Для методов - все 4 вида.

Шаг 3.

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

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

Наследование является важным, поскольку оно позволяет поддерживать концепцию иерархии классов (hierarchical classification). Применение иерархии классов делает управляемыми большие потоки информации.

Разберем этот механизм на классическом примере: Геометрические фигуры.

У нас есть интерфейс Figure:

Public interface Figure { public void draw (); public void erase (); public void move (); public String getColor (); public boolean setColor (); }

Интерфейс (более детально будут рассмотрены в скором будущем ) - нам говорит, как должен выглядеть класс, какие методы в себе содержать, какими переменными и типами данных манипулировать. Сам интерфейс не реализует методы, а создает как бы скелет для класса, который будет расширять этот интерфейс. Есть класс Figure, который расширяет интерфейс Figure:

Public class Figure implements сайт.oop.inheritance.interfaces.Figure{ @Override public void draw() { //need to implement } @Override public void erase() { //need to implement } @Override public void move(int pixel) { //need to implement } @Override public String getColor() { return null; } @Override public boolean setColor(String colour) { return false; } }

В этом классе мы реализуем все методы интерфейса Figure .

public class Figure implements сайт.oop.inheritance.interfaces.Figure - с помощью ключевого слова implements мы перенимаем методы интерфейса Figure для реализации.

Важно: в классе должны быть все методы интерфейса, даже если некоторые еще не реализованы, в противном случае компилятор будет выдавать ошибку и просить подключить все методы. Тело методов можно изменить только в интерфейсе, здесь только реализация.
@ Override - аннотация которая говорит что метод переопределен.

И соответственно у нас есть 3 класса самих фигур, которые наследуются от класса Figure. Класс Figure является родительским классом или классом-родителем, а классы Circle, Rectungle и Triangle - являются дочерними.

Public class Circle extends Figure { @Override public void draw() { super.draw(); } @Override public void erase() { super.erase(); } @Override public void move(int pixel) { super.move(pixel); } @Override public String getColor() { return super.getColor(); } @Override public boolean setColor(String colour) { return super..oop.inheritance.Figure{ @Override public void draw() { super.draw(); } @Override public void erase() { super.erase(); } @Override public void move(int pixel) { super.move(pixel); } @Override public String getColor() { return super.getColor(); } @Override public boolean setColor(String colour) { return super..oop.inheritance.Figure{ @Override public void draw() { super.draw(); } @Override public void erase() { super.erase(); } @Override public void move(int pixel) { super.move(pixel); } @Override public String getColor() { return super.getColor(); } @Override public boolean setColor(String colour) { return super.setColor(colour); } }

public class Triangle extends сайт.oop.inheritance.Figure - это значит, что класс Triangle наследует класс Figure .

super.setColor(colour); - super модификатор, позволяющий вызывать методы из класса родителя.

Теперь каждый класс перенял свойства класса Figure. Что собственно это нам дало?

Значительно уменьшило время разработки классов самих фигур, дало доступ к полям и методам родительского класса.

Наверное возник вопрос: чем же extends отличается от implements ?

Extends дает нам намного гибче подход. Мы используем только те методы, что нам нужны, в любой момент мы можем изменить каркас и тело метода, или добавить совсем новый метод, который возможно будет использовать информацию от класса родителя, а implements все лишь формирует тело класса.

В дочерних классах мы можем спокойно добавлять новые интересующие нас методы. Например, мы хотим добавить в класс Triangle 2-а новых метода: flimHorizontal () и flipVertical ():

/** * New Method */ public void flipVertical () { }; /** * New Method */ public void flipHorizontal () { };

Теперь эти 2-а метода принадлежат сугубо классу Triangle . Этот подход используется когда базовый класс не может решить всех проблем.

Или можно использовать другой подход, изменить или переписать методы в дочерним классе:

Довольно интересный факт: в java запрещено множественное наследование, но любой из классов по умолчанию наследуется то класса Object . То есть при наследовании любого класса у нас получается множественное наследование)

Но не стоит забивать этим голову!

Шаг 4.

Полиморфизм.

В более общем смысле, концепцией полиморфизма является идея “один интерфейс, множество методов “.

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

Вам, как программисту, не нужно делать этот выбор самому. Нужно только помнить и использовать общий интерфейс.

Public class Parent { int a = 2; } public class Child extends Parent { int a = 3; }

Прежде всего, нужно сказать, что такое объявление корректно.

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

Компилятор может опираться только на тип ссылки, с помощью которой происходит обращение к полю:

Child c = new Child(); System.out.println(c.a); // результатом будет 3 Parent p = c; System.out.println(p.a); //результатом будет 2

Данное объявление так и называется – «скрывающим ». Родительское поле продолжает существовать.

К нему можно обратиться явно:

Class Child extends Parent { int a = 3; //скрывающее объявление int b = ((Parent)this).a; //громоздкое обращение к родительскому полю int c = super.a; //простое обращение к родительскому полю }

Переменные b и c получат значения, родительского поля a . Хотя выражение с super более простое, оно не позволит обратиться на два уровня вверх по дереву наследования.

А ведь вполне возможно, что в родительском классе это поле также было скрывающим и в родителе родителя храниться ещё одно значение.

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

Class Parent { int x = 0; public void printX() { System.out.println(x); } } class Child extends Parent { int x = -1; }

Каков будет результат для new Child.printX() ; ?

Метод вызывается с помощью ссылки типа Child , но метод определен в классеParent и компилятор расценивает обращение к полю x в этом методе именно как к полю класса Parent . Результатом будет 0 .

Рассмотрим случай переопределения методов:

Class Parent { public int getValue() { return 0; } } class Child extends Parent { public int getValue() { return 1; } } Child c = new Child(); System.out.println(c.getValue()); // результатом будет 1 Parent p = c; System.out.println(p.getValue()); // результатом будет 1

Родительский метод полностью перекрыт.

В этом ключевая особенность полиморфизма – наследники могут изменить родительское поведение, даже если обращение к ним производиться по ссылке родительского типа.

Хотя старый метод снаружи недоступен, внутри класса-наследника к нему можно обратиться с помощью super .

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

Шаг 5.

Абстракция:

Как говорилось в начале статьи, нельзя игнорировать абстракцию, а значит и абстрактные классы и методы.

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

Перемещая переменные или методы из подкласса в супер класс, вы обобщаете их. Это общие понятия, и они применимы в языке Java. Но язык добавляет также понятия абстрактных классов и абстрактных методов .

Абстрактный класс является классом, для которого нельзя создать экземпляр.

Например, вы можете создать класс Animal (животное). Нет смысла создавать экземпляр этого класса: на практике вам нужно будет создавать экземпляры конкретных классов , например, Dog (собака). Но все классы Animal имеют некоторые общие вещи, например, способность издавать звуки. То, что Animal может издавать звуки, еще ни о чем не говорит.

Издаваемый звук зависит от вида животного.

Как это смоделировать?

Определить общее поведение в абстрактном классе и заставить подклассы реализовывать конкретное поведение, зависящее от их типа.

В иерархии могут одновременно находиться как абстрактные, так и конкретные классы.

Использование абстракции:

Наш класс Person содержит некоторый метод поведения, и мы пока не знаем, что он нам необходим. Удалим его и заставим подклассы реализовывать это поведение полиморфным способом. Мы можем сделать это, определив методы Person как абстрактные. Тогда наши подклассы должны будут реализовывать эти методы.

Public abstract class Person { abstract void move(); abstract void talk(); } public class Adult extends Person { public Adult() { } public void move() { System.out.println("Walked."); } public void talk() { System.out.println("Spoke."); } } public class Baby extends Person { public Baby() { } public void move() { System.out.println("Crawled."); } public void talk() { System.out.println("Gurgled."); } }

Что мы сделали в приведенном выше коде?

Мы изменили Person и указали методы как abstract , заставив подклассы реализовывать их.
Мы сделали Adult подклассом Person и реализовали эти методы.
Мы сделали Baby подклассом Person и реализовали эти методы.

Объявляя метод абстрактным, вы требуете от подклассов либо реализации этого метода, либо указания метода в этих подклассах абстрактным и передачи ответственности по реализации метода к следующим подклассам. Можно реализовать некоторые методы в абстрактном классе и заставить подклассы реализовывать остальные. Это зависит от вас. Просто объявите методы, которые не хотите реализовывать, как абстрактные и не предоставляйте тело метода. Если подкласс не реализует абстрактный метод супер класса, компилятор выдаст ошибку.

Теперь, поскольку Adult и Baby являются подклассами Person , мы можем обратиться к экземпляру каждого класса как к типу Person.

Возможно, будет полезно почитать: