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

1 year ago | 13.4K

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

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

Введение в ООП

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

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

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

Процедурное программирование:

$value = "Hi!"; echo $value;

ООП:

class Human { private $words; public function setWords($words) { $this->words = $words; } public function getWords() { return $this->words; } public function sayIt() { return $this->getWords(); } } $human = new Human(); $human->setWords("Hi!"); echo $human->sayIt();

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

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

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

Что из себя представляет КЛАСС

Здесь все достаточно просто - это методы, а также, поля программы. В качестве примера можно рассмотреть Human:

Class Human { private $words; public function setWords($words) { $this->words = $words; } public function getWords() { return $this->words; } public function sayIt() { return $this->getWords(); } }

Здесь все достаточно просто, Human является именем класса, $words представляет собой переменную (поле), ну а setWords, getWords(), sayIt(), являются методами.

Несколько базовых принципов ООП

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

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

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

Чтобы сразу же стало понятно что это, приведем реальный пример.

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

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

Приведем в качестве примера инкапсуляции следующее:

Class Human { private $words; private $sex; public function setSex($sex) { if($sex == "male") { $this->sex = "male"; } else if($sex == "female") { $this->sex = $sex; } else { echo "Error. Set only male or female sex"; } } public function setWords($words) { $this->words = $words; } public function getWords() { return $this->words; } public function sayIt() { return $this->getWords(); } } $human = new Human(); $human->setSex("male"); $human->setWords("Hi!"); echo $human->sayIt();

Здесь показан Human, в данном классе мы добавили “sex” (пол), которое сделали приватным - это не позволит внешним пользователям получить к нему доступ.

Вот как будет выглядеть попытка получения доступа к данному поля вне самого класса:

$human->sex = "11"; Fatal error: Cannot access private property Human::$sex

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

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

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

И снова жизненный пример, который поможет разобраться с особенностями наследования.

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

Вы являетесь соединением огромного количества цепочек генов - от самых первых предков и до кровных родителей. Если рассматривать ООП - то в данном случае свойство наследования ничем не отличается от простой жизни.

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

/* Родительский класс Human */ class Human { private $name; /* Конструктор (в нем мы задаем поле $name при создании экземпляра класса) */ public function __construct($name) { $this->name = $name; } /* Метод say(). Предполагаем, что Human изначально может говорить */ public function say() { echo "Меня зовут ".$this->name." и "; } } /* Класс Мужчина. Ключевым словом extends мы наследуем родителя Human */ class Man extends Human { public function beard() { echo "у меня растет борода"; } } /* Класс Женщина. Ключевым словом extends мы наследуем родителя Human */ class Women extends Human { public function bearChildren() { echo "я рожаю детей"; } } /* Создаем экземпляр класса Man и вызываем методы. */ $man = new Man("Sergey"); $man->say(); $man->beard(); /* Создаем экземпляр класса Women и вызываем методы. */ $women = new Women("Maria"); $women->say(); $women->bearChildren();

Что же мы увидим в результате:

Меня зовут Sergey и у меня растет борода Меня зовут Maria и я рожаю детей

Если рассматривать созданные классы - они оба обладают базовым набором навыков, но есть свои отличия - "Мужчина" отращивает бороду, "Женщина" рожает ребенка.

Метод под названием __construct - это конструктор класса.

Полиморфизм

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

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

Ну как? Теперь проще понять разное поведение одного метода в ООП?

Пример полиморфизма:

/* Это интерфейс Say */ interface Say { public function say(); } /* Это абстрактный класс Human имплементирующий интерфейс Say */ abstract class Human implements Say{ private $name; public function __construct($name) { $this->name = $name; } public function getName() { return $this->name; } } /* Класс Man наследуют класс Human и обязан реализовать метод say() */ class Man extends Human { public function __construct($name) { parent::__construct($name); } public function beard() { echo "у меня растет борода"; } public function say() { echo "У меня мужской голос, меня зовут ".$this->getName()." и "; } } /* Класс Women наследуют класс Human и обязан реализовать метод say() */ class Women extends Human { public function __construct($name) { parent::__construct($name); } public function bearChildren() { echo "я рожаю детей"; } public function say() { echo "У меня женский голос, меня зовут ".$this->getName()." и "; } } $man = new Man("Sergey"); $man->say(); $man->beard(); $women = new Women("Maria"); $women->say(); $women->bearChildren(); ?>

Результат:

У меня мужской голос, меня зовут Sergey и у меня растет борода У меня женский голос, меня зовут Maria и я рожаю детей

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

Обратите внимание на разную реализацию метода say() в классах Man, а также, Women - Это называется полиморфизм.

Особенности Интерфейса

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

Рассмотрим прошлый пример:

/* Это интерфейс Say */ interface Say { public function say(); }

Данный интерфейс необходимо имплементировать в абстрактный класс Human. Сделать это достаточно просто - находим название класса, и сразу же после него добавляем "implements".

Абстрактный класс

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

Пример того, чего мы не сможем сделать:

$human = new Human("name");

В любом случае будем получать ошибку.

Есть возможность наследования Абстрактного класса. Еще один пример Абстрактного класса:

/* Это абстрактный класс Human имплементирующий интерфейс Say */ abstract class Human implements Say{ private $name; public function __construct($name) { $this->name = $name; } public function getName() { return $this->name; } }

Выводы

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

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

Мы привели достаточно простые примеры - это отличная возможность для любого новичка в сегменте программирования! Надеемся, что помогли вам понять особенности ООП, изучить наиболее важные принципы, чтобы в дальнейшем совершенствовать свои умения. Несколько будущих статей будут направлены на то, чтобы разобраться с важными ключевыми словами public, private, protected, static. Увидеть все особенности на весьма простых примерах.

От переводчика: К сожалению, у меня нет сколько-нибудь значительного опыта перевода с английского, хотя я и довольно много читаю на английском. Но выяснилось, что читать и переводить – разные вещи. Также, к сожалению, у меня нет значительного опыта в программировании (недавно только сделал простейшее веб-приложение на Spring MVC и Hibernate). Поэтому перевод получился значительно хуже, чем мог бы быть. Я взял на себя смелость несколько подкорректировать примеры кода, которые даются в статье, так как они не соответствуют соглашениям по наименованию (code conventions) в Java. Возможно, не стоило переводить название некоторых паттернов (такой перевод мало что дает для понимания), но я посчитал, что это меньшее зло. Отдельно стоит сказать о "высокой сцепленности" как переводе "high cohesion". Согласен, не самый лучший перевод. Но "сильная связность" - это "high coupling" (другое важное понятие), а "когерентность" здесь вряд ли подойдет. Я открыт для критики и с признательностью приму замечания по статье в любой форме. Объектно-ориентированное программирование – это стиль программирования, в котором программа состоит из компонентов, соответствующих объектам реального мира Любой реальный объект имеет какие-то свойства (которые могут изменяться или нет с течением времени) и поведение (которое может меняться или нет в зависимости от других условий). Например, карандаш – это объект реального мира, который имеет следующие свойства:

Он красный (это не меняется с течением времени).
Он 10 сантиметров в длину сейчас (это может меняться, если карандаш заточить).

И он имеет следующее поведение:

Он оставляет след, если его использовать правильно.
След может отличаться в зависимости от давления (зависит от внешних факторов).
Его длина сокращается, если его затачивать (постоянное поведение).

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

Абстракция

Абстракция определяется как характерная черта (quality) взаимодействия с идеями, а не событиями или, другими словами, свобода от репрезентирующих качеств . Это позволяет программистам сфокусироваться на том, что программировать, а не как . Абстракцию можно рассматривать в качестве соглашения, посредством которого мы предоставляем функциональность. Детали реализации могут быть скрыты, если использовать этот концепт. Например, если нам нужен класс, который пишет, то мы должны быть уверены, что обладает методов «писать» abstract class writer { write (); } Что мы сделали? Мы разработали класс высокого уровня, являющийся абстрактными, иными словами, он знает, что за функциональность нам нужна, но как ее реализовать – это за пределами видимости (out of scope) данного класса. Это дает много преимуществ:

Мы раскрываем минимум информации необходимой внешним сущностям, это позволяет сосредоточиться на продумывании программы (this enable focused thinking), избежать путаницы и не давать непреднамеренных обещаний.
Мы оставляем место для улучшений в будущем, которые были бы невозможны, если детали реализации были раскрыты.

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

«Наследование» в общеупотребительном английском означает «приобретать и передавать дальше». Это слова существует в нашей культуре очень давно. Предки приобретали землю с помощью тяжелой работы и передавали ее своим детям, даже природа благоволит наследованию. Все свойства тела, например, рост, цвет кожи/глаз/волос и т.д. зависят от генов, наследуем нами от наших родителей. Наследование предотвращает изобретение колеса заново и ускоряет прогресс. То же самое и в ООП. Мы создаем родительский класс с несколькими базовыми свойствами/поведением. Все классы, наследуемые от этого родителя, будут содержать такие же свойства/поведение, что и их родитель. Тем не менее, наследуемые классы могут получить больше свойств/поведения или изменить реализацию поведения. class WritingInstrument { colour; write() { } } class Pen (child of parent) { inkcolour; } В примере сверху класс-родитель (WritingInstrument) имеет свойство «цвет» и поведение «писать». Когда класс-наследник (ручка) объявляется, повторное объявление свойства «цвет» и поведения «писать» не требуется. Они присутствуют в классе «ручка» в силу наследования. Однако класс-наследник может объявить собственные дополнительные свойства/поведение. Как мы можем использовать это на практике? Мы, разработчики, очень ленивы. Мы не хотим печатать что-то снова и снова. Существование множества копий одного и того же кода не приветствуется в силу следующих соображений:

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

Наследование в Java достигается с помощью ключевых слов «extends» и «implements». class WritingInstrument { } class Pen extends WritingInstrument { }

Полиморфизм

Слова «полиморфизм» произошло от двух слов: «Поли» , т.е. «множество» / «больше, чем один» «морф» , т.е. «форма» Буквально, слово «полиморфизм» отсылает к способности объектов вести себя различным образом в зависимости от условий. В программировании полиморфизм может быть воплощен в нескольких местах:

Классы
Методы
Операторы

Все, перечисленное выше, может вести себя различным образом в зависимости от условий, возможно, от контекста, в которых они используются. Это полезно, так как клиенту (программисту, использующему ваши библиотеки) не нужно знать множество тонкостей, и желаемая функциональность реализуется посредством отбора необходимой информации из контекста. Class WritingObject { wrire() { // пишем, используя стандартные (по дефолту) цвета } } class Pencil extends WritingObject { write() { // пишем, используя серый цвет, написанный текст можно стереть } } class Pen extends WritingObject { write() { // пишем, используя голубой цвет, написанный текст нельзя стереть } } class Main { main() { WritingObject wr = new WritingObject(); wr.write(); // первый вызов WritingObject wr = new Pen(); wr.write(); // второй вызов WritingObject wr2 = new Pencil(); wr2.write(); // третий вызов } } В примере выше имеет реализация по умолчанию в WritingObject, которая расширена/переопределена классами-наследниками перо и ручка. Метод write() вызван три раза в классе Main. Каждый раз вызывается различная реализация в зависимости от того, у какого объекта вызывается этот метод. В данном случае метод write() имеет множество типов поведения, так как он полиморфичен.

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

Инкапсуляция определяется как сбор связанных данный/функциональностей в одном модуле (unit). Это помогает в облегчении доступа/модификации данных. Например, если нам нужно напечатать все свойства, которыми данный пользователь обладает, мы имеем следующие опции: printUserProperties(userName, userId, firstname, lastname, email, phone, … … ….) Мы создали метод, который принимает все свойства и печатает их друг за другом. С увеличением количества элементов в списке пропадет возможность идентифицировать корректные поля, а добавление/удаление одного поля изменит сигнатуру метода. Поэтому нам нужно заменить всех пользователей этого метода, если даже недавно добавленные поля им не нужны. Чтобы сделать код более читаемым и упростить будущие модификации проще, мы инкапсулируем свойства в классе и превращаем его в коллективный объект (collective object) class User { userName userId firstname lastname email phone .. .. .. } printUserProperties(user) {} Объект – это система (software bundle) переменных и связанных методов. Вы можете представить объекты реального мира, используя объекты программы. Вы можете представить реальных собак в анимационной программе или реальный велосипед как программный объект внутри велотренажера. В ООП класс – расширяемый шаблон (program-code-template) для создания объектов, обеспечения их начальным состоянием (переменные) и реализацией поведения (функции, методы). Аббревиатура SOLID была введена Michael Feather’ом для «первых пяти принципов», названных так Robert C. Martin’ом в начале 2000-х. Целью принципов, реализуемых совместно, является увеличение вероятности того, что программист создаст систему, которую легко будет поддерживать и расширять. – ориентиры в разработке программ, которые необходимы для удаления «протухшего» кода посредством рефакторинга, в результате которого код должен стать легко читаемым и расширяемым. Это часть стратегии agile and adaptive programming (гибкого и адаптирующегося программирования).

Принцип единой ответственности (Single Responsibility Principle)

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

Принцип открытости/закрытости (Open/Closed Principle)

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

Принцип подстановки Лисковой (Liskov Substitution Principle)

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

Принцип разделения интерфейса (Interface Segregation Principle)

Принцип разделения интерфейса гласит, что программист-клиент не должен быть принужден зависеть от методов, которые он не использует. Согласно этому принципу нужно разделять большие интерфейсы на маленькие и более специфичные, чтобы программист-клиент знал только о методах, которые ему интересны. Целью принципа разделения интерфейса является сохранение системы в несвязанном состоянии (system decoupled), что облегчит рефакторинг, внесение изменений и повторное развертывание (redeploy).

Принцип инверсии зависимостей (Dependency Inversion Principle)

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

Модули высокого уровня не должны зависеть от модулей низкого уровня. Модули обоих типов должны зависеть от абстракций.
Абстракции не должны зависеть от деталей реализации. Детали должны зависеть от абстракций.

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

Принципы GRASP

Паттерны (принципы), используемые для решения общих задач по назначению обязанностей классам и объектам (General Responsibility Assignment Software Patterns (GRASP)) содержат руководства (guidelines) по назначению ответственности классам и объектам в объектно-ориентированном дизайне.

Контроллер (Controller)

Паттерн Контроллер назначает ответственность за взаимодействие с системными событиями классов без графического интерфейса, которые представляют всю систему или use case scenario (сценарии вариантов использования). Контроллер:

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

Создатель (Creator)

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

Высокая сцепленность (High Cohesion)

Высокая сцепленность – оценочный паттерн, целью применения которого является сохранение объектов в таком состоянии, чтобы они были нацелены на выполнение одной четкой задачи, легко управляемы и понимаемы. Высокая сцепленность обычно используется для поддержки слабой связности (Low Coupling). Высокая связность означает, что ответственность данного элемента четко обозначена (strongly related and highly focused). Разбиение программы на классы и подсистемы – пример действий, что повышает сцепленность свойств системы. Слабая сцепленность, наоборот, - ситуация, в которой элемент имеет слишком много несвязанных задач. Элементы со слабой сцепленностью обычно отличаются тем, что их сложно понять, сложно повторно использовать, поддерживать и изменять.

Окольный путь (Indirection)

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

Информационный эксперт (Information Expert)

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

Слабая связность (Low Coupling)

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

Полиморфизм (Polymorphism)

В соответствии с полиморфизмом изменения поведения основывается на типе объекта, на который ссылается переменная (responsibility of defining the variation of behaviors based on type is assigned to the types for which this variation happens). Это достигается использованием полиморфных операций.

Защищенные изменения (Protected Variations)

Паттерн Защищенные изменения защищает элементы от изменений других элементов (объектов, систем, подсистем) путем обертывания центра нестабильности (the focus of instability) интерфейсом и использования полиморфизма для создания различных реализаций данного интерфейса.

Чистое конструирование (Pure Fabrication)

Чистое конструирование предполагает класс, не представляющий концепт в проблемной области (the problem domain) и созданный специально для достижения слабой связности, высокой сцепленности и, следовательно, максимального потенциала повторного использования (решение, предлагаемое паттерном Информационный эксперт этого не обеспечивает). Такая класс обычно называется “Service” в Предметно-ориентированном дизайне (Domain-driven design).

Критика

Исследования Potok’a и др. показали отсутствие существенных различий между ООП и процедурными подходами.

Критическое сравнение ООП с другими технологиями, в особенности реляционными, затруднено в силу отсутствия определения ООП, которое было бы строгим и широко принятым (Christopher J. Date)

В сравнении с другими языками (LISP диалекты, функциональные языка и т.д.) ООП языки не имеют уникального преимущества и навязывают ненужную сложность. (Lawrence Krubner)

Я нахожу объектно-ориентированное программирование технически неосновательным. Оно пытается разложить мир на части в терминах интерфейсов, которые изменяются в пределах одного типа. Чтобы иметь дело с реальными проблемами, вам нужны многосортные алгебры - семейства интерфейсов, которые простираются на многие типы. Я нахожу объектно-ориентированное программирование философски нездоровым. Оно утверждает, что всё является объектом. Даже если это так, это не очень интересно: сказать, что всё является объектом -- значит, не сказать вообще ничего. (Александр Степанов)

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

Объектно-ориентированное программирование ставит существительные первыми и самыми главными. Зачем идти на такие крайние меры и ставить одну часть речи на пьедестал? Почему один концепт получает преимущество над другим? Это невозможно, чтобы ООП внезапно сделало глаголы менее важными для нашего мышления. Это странным образом перекошенная перспектива. (Steve Yegge)

Rick Hickey, создатель Clojure, описывал объектные системы как крайне упрощенные модели реального мира. Он подчеркивал неспособность ООП моделирования времени правильно, что создает огромные проблемы, когда в программах большое распространение получает многопоточность. Eric S. Raymond, Unix-программист и сторонник программного обеспечения с открытым кодом, был критически настроен в отношении заявления, что ООП является «Единственно верным решением», и писал, что ООП поощряет многослойные программы, что препятствует понятности (transparency). В качестве противоположного подхода Raymond приводил пример Unix и С.

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

Первый ряд примеров событий доставляет собственно сам жизненный цикл объекта:

создание объекта;
уничтожение объекта.

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

Современными языками объектно-ориентированного программирования являются С++ и Java . С середины 90-х годов многие объектно–ориентированные языки реализуются как системы визуального программирования , в которых интерфейсная часть программного продукта создается в диалоговом режиме, практически без написания программных операторов. К объектно – ориентированным системам визуального проектирования относятся Visual Basic , Delphi , C++ Builder , Visual C++. Язык VBA (Visual Basic for Applications) – язык приложений Microsoft Office (Excel , Word , Access , Power Point и др). VBA соблюдает основной синтаксис языка и правила программирования языков Basic – диалектов, позволяет создавать макросы для автоматизации выполнения некоторых операций и графический интерфейс пользователя, интеграцию между различными программными продуктами.

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

Лабораторные работы

Объектно-ориентированное программирование для начинающих
Лабораторная работа 1 по Adobe Flash: Рисование и закрашивание
Лабораторная работа 2 по Adobe Flash: Символы и их трансформы
Лабораторная работа 7 по Adobe Flash: Кадрированная анимация
Лабораторная работа 9 по Adobe Flash: Вставка Flash-объекта в html-файл
ООП в JavaScript. Лабораторная работа 1
Основные понятия и определения: объект, метод, свойства, события
ООП в JavaScript. Лабораторная работа 3. Форма, кнопка, текстовое поле
ООП в JavaScript. Лабораторная работа 4. Типы данных. Переменные. Арифметические операции. Условная операция
Введение в интерфейс, объекты и новые возможности MS Access 2007
Лаб.2. Модификация базы данных. Использование связанных таблиц. Создание форм и отчетов

Литература

Бруно Бабэ. Просто и ясно о Borland C++: Версии 4.0 и 4.5/ Пер. с англ. -М.:БИНОМ, 1994. - 400с.
Буч Г. «Объектно-ориентированный анализ и проектирование с примерами приложений на С++» Пер. с англ. - М.: Бином; СПб.: Невский диалект, 1999.
. - М, 2000
Гайсарян С.С. «Объектно-ориентированное проектирование» (http://www.mista.ru/oop_book/index.htm)
Жуков А. «Изучаем С» - СПб.: Питер, 2003.
- Adobe Systems, 2010.
Ишкова Э. «С++ начала программирования» - М.: Бином, 2001.
Клочков Д.П., Павлов Д.А. Введение в объектно-ориентированное программирование. / Учебно-методическое пособие. - Изд. Нижегор. ун-та, 1995. - 70с.
Легалов А. «Итоги экспансии объектно-ориентированной парадигмы» (http://www.softcraft.ru/paradigm/process/pr01.shtml
Мухортов В.В., Рылов В.Ю. (методическое пособие) - ИМСО РАН, Новосибирск, 2002
Немнюгин С., Перколаб Л. «Изучаем TurboPascal
Плискин М. «Эволюция языков программирования» (://2..cctpu../edu///lang/_09.)
. - МИФИ, 2003
Объектно-ориентированная методология программирования (http://www.math.rsu.ru/smalltalk/sml-a.ru.html)
Объектно-ориентированные системы: состояние и перспективы. Аналитический обзор по материалам фирмы OVUM. Обзор подготовил А.Г. Иванов. (http://www.math.rsu.ru/smalltalk/obzornew.ru.html)
Объектно-ориентированные языки программирования. Сравнение с традиционными языками (://.suvvbcourse/1.)
Патрикеев Ю.Н. «Объектно-ориентированное проектирование» (http://www.object.newmail.ru/oop1.html)
Патрикеев Ю.Н. «Объектно-ориентированное программирование на Borland C++» (http://www.object.newmail.ru/obj0.html)
Принципы объектно-ориентированного программирования – Лекции по системе визуального объектно-ориентированного проектирования Delphi - Лекции (http://blackman.wp-club.net/lection/visualprg.php)
Стили программирования (http://media.karelia.ru/~ftt/IVK/new2/Inflect/T_1_16.htm)
Страуструп Б. Язык программирования С++ (2-ред)./Пер. с англ.-М.: Радио и связь, 1995. - 352с.

Так объекты сформировались в компоненты - независимые части кода до уровня выполнения программы . Взаимодействие объектов происходит посредством . Результатом дальнейшего развития ООП, по-видимому, будет агентно-ориентированое программирование , где агенты - независимые части кода на уровне выполнения. Взаимодействие агентов происходит посредством изменения среды , в которой они находятся.

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

Первым языком программирования, в котором были предложены принципы объектной ориентированности, была Симула . В момент своего появления (в 1967 году), этот язык программирования предложил поистине революционные идеи: объекты, классы, виртуальные методы и др., однако это всё не было воспринято современниками как нечто грандиозное. Тем не менее, большинство концепций были развиты Аланом Кэйем и Дэном Ингаллсом в языке Smalltalk . Именно он стал первым широко распространённым объектно-ориентированным языком программирования .

В настоящее время количество прикладных языков программирования (список языков), реализующих объектно-ориентированную парадигму, является наибольшим по отношению к другим парадигмам. В области системного программирования до сих пор применяется парадигма процедурного программирования, и общепринятым языком программирования является язык . Хотя при взаимодействии системного и прикладного уровней операционных систем заметное влияние стали оказывать языки объектно-ориентированного программирования. Например, одной из наиболее распространенных библиотек мультиплатформенного программирования является объектно-ориентированная библиотека , написанная на языке C++ .

Основные понятия

В этом разделе не хватает ссылок на источники информации.

Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена.
Вы можете отредактировать эту статью, добавив ссылки на авторитетные источники.
Эта отметка установлена 18 октября 2012 .

Абстракция Абстрагирование - это способ выделить набор значимых характеристик объекта, исключая из рассмотрения незначимые. Соответственно, абстракция - это набор всех таких характеристик. Инкапсуляция Инкапсуляция - это свойство системы, позволяющее объединить данные и методы, работающие с ними в классе, и скрыть детали реализации от пользователя. Наследование Наследование - это свойство системы, позволяющее описать новый класс на основе уже существующего с частично или полностью заимствующейся функциональностью. Класс, от которого производится наследование, называется базовым, родительским или суперклассом. Новый класс - потомком, наследником или производным классом. Полиморфизм Полиморфизм - это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта. Класс Класс является описываемой на языке терминологии (пространства имён) исходного кода моделью ещё не существующей сущности (объекта). Фактически он описывает устройство объекта, являясь своего рода чертежом. Говорят, что объект - это экземпляр класса. При этом в некоторых исполняющих системах класс также может представляться некоторым объектом при выполнении программы посредством динамической идентификации типа данных . Обычно классы разрабатывают таким образом, чтобы их объекты соответствовали объектам предметной области. Объект Сущность в адресном пространстве вычислительной системы, появляющаяся при создании экземпляра класса или копирования прототипа (например, после запуска результатов компиляции и связывания исходного кода на выполнение). Прототип Прототип - это объект-образец, по образу и подобию которого создаются другие объекты. Объекты-копии могут сохранять связь с родительским объектом, автоматически наследуя изменения в прототипе; эта особенность определяется в рамках конкретного языка .

Определение ООП и его основные концепции

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

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

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

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

Сложности определения

ООП имеет уже более чем сорокалетнюю историю, но, несмотря на это, до сих пор не существует чёткого общепринятого определения данной технологии . Основные принципы, заложенные в первые объектные языки и системы, подверглись существенному изменению (или искажению) и дополнению при многочисленных реализациях последующего времени. Кроме того, примерно с середины 1980-х годов термин «объектно-ориентированный» стал модным , в результате с ним произошло то же самое, что несколько раньше с термином «структурный» (ставшим модным после распространения технологии структурного программирования) - его стали искусственно «прикреплять» к любым новым разработкам, чтобы обеспечить им привлекательность. Бьёрн Страуструп в 1988 году писал, что обоснование «объектной ориентированности» чего-либо, в большинстве случаев, сводится к ложному силлогизму : «X - это хорошо. Объектная ориентированность - это хорошо. Следовательно , X является объектно-ориентированным».

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

Концепции

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

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

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

Однако общность механизма обмена сообщениями имеет и другую сторону - «полноценная» передача сообщений требует дополнительных накладных расходов, что не всегда приемлемо. Поэтому в большинстве ныне существующих объектно-ориентированных языков программирования используется концепция «отправка сообщения как вызов метода» - объекты имеют доступные извне методы, вызовами которых и обеспечивается взаимодействие объектов. Данный подход реализован в огромном количестве языков программирования, в том числе C++ , Object Pascal , Java , Oberon-2 . В настоящий момент именно он является наиболее распространённым в объектно-ориентированных языках.

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

Особенности реализации

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

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

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

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

Инкапсуляция обеспечивается следующими средствами

Контроль доступа Поскольку методы класса могут быть как чисто внутренними, обеспечивающими логику функционирования объекта, так и внешними, с помощью которых взаимодействуют объекты, необходимо обеспечить скрытость первых при доступности извне вторых. Для этого в языки вводятся специальные синтаксические конструкции, явно задающие область видимости каждого члена класса. Традиционно это модификаторы public, protected и private, обозначающие, соответственно, открытые члены класса, члены класса, доступные только из классов-потомков и скрытые, доступные только внутри класса. Конкретная номенклатура модификаторов и их точный смысл различаются в разных языках. Методы доступа Поля класса, в общем случае, не должны быть доступны извне, поскольку такой доступ позволил бы произвольным образом менять внутреннее состояние объектов. Поэтому поля обычно объявляются скрытыми (либо язык в принципе не позволяет обращаться к полям класса извне), а для доступа к находящимся в полях данным используются специальные методы, называемые методами доступа. Такие методы либо возвращают значение того или иного поля, либо производят запись в это поле нового значения. При записи метод доступа может проконтролировать допустимость записываемого значения и, при необходимости, произвести другие манипуляции с данными объекта, чтобы они остались корректными (внутренне согласованными). Методы доступа называют ещё аксессорами (от англ. access - доступ), а по отдельности - геттерами (англ. get - чтение) и сеттерами (англ. set - запись) . Свойства объекта Псевдополя, доступные для чтения и/или записи. Свойства внешне выглядят как поля и используются аналогично доступным полям (с некоторыми исключениями), однако фактически при обращении к ним происходит вызов методов доступа. Таким образом, свойства можно рассматривать как «умные» поля данных, сопровождающие доступ к внутренним данным объекта какими-либо дополнительными действиями (например, когда изменение координаты объекта сопровождается его перерисовкой на новом месте). Свойства, по сути - не более чем синтаксический сахар , поскольку никаких новых возможностей они не добавляют, а лишь скрывают вызов методов доступа. Конкретная языковая реализация свойств может быть разной. Например, в объявление свойства непосредственно содержит код методов доступа, который вызывается только при работе со свойствами, то есть не требует отдельных методов доступа, доступных для непосредственного вызова. В Delphi объявление свойства содержит лишь имена методов доступа, которые должны вызываться при обращении к полю. Сами методы доступа представляют собой обычные методы с некоторыми дополнительными требованиями к сигнатуре.

Полиморфизм реализуется путём введения в язык правил, согласно которым переменной типа «класс» может быть присвоен объект любого класса-потомка её класса.

Подходы к проектированию программ в целом

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

Объектно-ориентированное проектирование состоит в описании структуры и поведения проектируемой системы, то есть, фактически, в ответе на два основных вопроса:

Из каких частей состоит система .
В чём состоит ответственность каждой из частей .

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

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

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

Родственные методологии

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

Компонентное программирование

Примечания

См. также

ORM - технология связывания ОО-программ c базами данных

Литература

Иан Грэхем. Объектно-ориентированные методы. Принципы и практика = Object-Oriented Methods: Principles & Practice. - 3-е изд. - М .: «Вильямс», 2004. - С. 880. - ISBN 0-201-61913-X
Антони Синтес. Освой самостоятельно объектно-ориентированное программирование за 21 день = Sams Teach Yourself Object-Oriented Programming in 21 Days. - М .: «Вильямс», 2002. - С. 672. - ISBN 0-672-32109-2

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

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

Сегодня существует достаточное количество объектно-ориентированных языков программирования , наиболее популярными из которых в настоящее время являются C++, Delphi, Java, Visual Basic, Flash. Но, кроме того, многие языки, которые принято причислять к процедурной парадигме, тоже обладают свойствами ООП, имея возможность работать с объектами. Так, объектно-ориентированное программирование в C — это большой раздел программирования на данном языке, то же самое касается ООП в python и многих других структурных языках.

Говоря об ООП, часто всплывает еще одно определение — визуальное программирование . Оно дополнительно предоставляет широкие возможности использования прототипов объектов, которые определяются как классы объектов.
События. Во многих средах визуального программирования реализована характеристика (помимо инкапсуляции, полиморфизма и наследования) объекта – событие. Событиями в объектно-ориентированном программировании называется возможность обработки так называемых сообщений (или событий), получаемых от операционной системы Windows или самой программы. Данный принцип характерен для всех компонентов среды, которые обрабатывают различные события, возникающие в процессе выполнения программы. По сути, событие — это некоторое действие, которое активизирует стандартную реакцию объекта. Событием может рассматриваться, например, щелчок по кнопке мыши, наведение курсора мыши на пункт меню, открытие вкладки и т.п. Очередность выполнения тех или иных действий определяется как раз таки событиями, возникающими в системе, и реакцией на них объектов.
Классы и объекты в ООП — различные понятия. Понятие класса в ООП – это тип данных (такой же как, например, Real или String), а объект – конкретный экземпляр класса (его копия), хранящийся в памяти компьютера как переменная соответствующего типа.
Класс является структурным типом данных. Класс включает описание полей данных, а также процедур и функций, которые работают с этими полями данных. Метод ООП – это и есть такие процедуры и функции применительно к классам.
Классы имеют поля (как тип данных запись — record), свойства, которые похожи на поля, но имеют дополнительные описатели, определяющие механизмы записи и считывания данных и методы — подпрограммы, которые направленны на изменение полей и свойств класса.

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

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

Принцип наследования ООП и подклассы

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

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

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

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