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

Понятие класса, экземпляра класса и объекта в ООП.

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

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

Но, для того, чтобы в нашей программе появился объект, нужно совершить два действия:

1) Его нужно описать. Какие свойства и методы есть у этого объекта.

2) Его нужно создать

Что значит описать объект? Описание объекта – это определение его свойств и методов, которые этот объект может принимать. Т.е. мы начинаем создавать программу и пишем, что у нас будет некий объект (например, Employee или Работник).

У этого объекта будет свойства first_name (имя), last_name (фамилия), age (возраст).

Этот объект при запросе к нему может выдавать его имя (getFirstName()), фамилию getLastName()), возраст (getAge()).

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

Что же значит создать объект?

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

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

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

Экземпляры классов = объекты.

Объект – это просто что-то конкретное, а класс – это некое абстрактное понятие, которое просто содержит описательную часть.

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

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

И нужно понимать, что

Чертеж НЕ равно деталь

Класс НЕ равно объект

Общий алгоритм работы с объектно-ориентированным подходом в программировании:

1. Создали класс
2. Создали экземпляр класса (объект)
3. Обращаемся к свойствам и методам экземпляра класса.

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

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ / Хабр

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

— Эдсгер Вибе Дейкстра

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

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

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

Данные важнее, чем код

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

Этот момент очень важен, так что я повторюсь: цель -> архитектура данных -> код. Здесь порядок менять ни в коем случае нельзя! При проектировании программы нужно всегда начинать с выяснения цели, которой нужно достичь, а затем хотя бы приблизительно представить архитектуру данных: структуры и инфраструктуру данных, необходимые для её эффективного достижения. И только после этого нужно писать код для работы с такой архитектурой. Если со временем цель меняется, то нужно сначала изменить архитектуру данных, а потом код.

По моему опыту, самая серьёзная проблема ООП заключается в том, что оно мотивирует игнорировать архитектуру модели данных и применять бестолковый паттерн сохранения всего в объекты, обещающие некие расплывчатые преимущества. Если это подходит для класса, то это отправляется в класс. У меня есть Customer? Он отправляется в class Customer. У меня есть контекст рендеринга? Он отправляется class RenderingContext.

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

Мотивирование к сложности

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

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

Повсюду графы

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

У вашего class Customer есть ссылка на class Order, и наоборот. class OrderManager содержит ссылки на все Order, а потому косвенно и на Customer. Всё стремится ссылаться на всё остальное, потому что постепенно в коде появляется всё больше мест, ссылающихся на связанный объект.

Вам нужен был банан, но вы получили гориллу, держащую банан, и целые джунгли.

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

Задачи поперечных срезов

Подавляющее большинство существенного кода не работает всего с одним объектом, а на самом деле реализует задачи поперечных срезов. Пример: когда class Player ударяет при помощи метода hits() class Monster, где на самом деле нужно изменять данные? Величина hp объекта Monster должна уменьшиться на attackPower объекта Player; величина xp объекта Player должна увеличиться на уровень Monster в случае убийства Monster. Должно ли это происходить в Player.hits(Monster m) или в Monster.isHitBy(Player p)? Что если здесь нужно учитывать и class Weapon? Мы передаём аргумент в isHitBy или у Player есть геттер currentWeapon()?

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

Шизофреническая инкапсуляция объектов

Давайте взглянем на определение инкапсуляции:

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

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

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

По моему мнению, классы и объекты слишком дробные, и с точки зрения изоляции, API и т.д. лучше работать в пределах «модулей»/«компонентов»/«библиотек». И по моему опыту, именно в кодовых базах ООП (Java/Scala) модули/библиотеки не используются. Разработчики сосредоточены на том, чтобы соорудить ограждения вокруг каждого класса, не особо задумываясь над тем, какие группы классов в совокупности формируют отдельную, многократно используемую, целостную логическую единицу.

На одинаковые данные можно смотреть по-разному

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

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

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

Низкая производительность

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

Какой же подход использовать вместо ООП?

Я не думаю, что существует «серебряная пуля», поэтому просто опишу то, как это обычно сегодня работает в моём коде.

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

Обычно если данные имеют значительный объём, моя структура близка к базе данных. То есть у меня будет некий объект, например DataStore с API, обеспечивающим доступ ко всем необходимым операциям для выполнения запросов и сохранения данных. Сами данные будут содержаться в виде структур ADT/PoD, а любые ссылки между записями данных будут представлены в виде ID (число, uuid или детерминированный хеш). По внутреннему устройству это обычно сильно напоминает или на самом деле имеет поддержку реляционной базы данных: Vecторы или HashMap хранят основной объём данных по Index или ID, другие структуры используются как «индексы», необходимые для выполнения быстрого поиска, и так далее. Здесь же располагаются и другие структуры данных, например кеши LRU и тому подобное.

Основная часть логики программы получает ссылку на такие DataStore и выполняет с ними необходимые операции. Ради параллелизма и многопоточности я обычно соединяю разные логические компоненты через передачу сообщений наподобие акторов. Пример актора: считыватель stdin, обработчик входящих данных, trust manager, состояние игры и т.д. Такие «акторы» можно реализовать как пулы подпроцессов, элементы конвейеров и т.п. При необходимости у них могут может быть собственный или общий с другими «акторами» DataStore.

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

Основная идея такова: только потому, что моё ПО работает в области, где есть концепции, например, клиентов и заказов, в нём не обязательно будет класс Customer и связанные с ним методы. Всё наоборот: концепция Customer — это всего лишь набор данных в табличной форме в одном или нескольких DataStore, а код «бизнес-логики» непосредственно манипулирует этими данными.

Дополнительное чтение

Как и многое в проектировании программного обеспечения, критика ООП — непростая тема. Возможно, мне не удалось чётко донести свою точку зрения и/или убедить вас. Но если вы заинтересовались, то вот ещё несколько ссылок:

Зачем нам ООП и что это такое / Хабр

Всем привет.

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

Начнем.

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

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

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

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

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

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

2. Полиморфизм. Печи ведь по-разному работают. Газовая потребляет газ, электро печь — электричество. Используя полиморфизм мы легко меняем поведение в наследниках абстрактной печи.

3. Инкапсуляция. Основная фишка инкапсуляции в том, что я не должен знать, что происходит внутри моей печи. Допустим, я вызываю не метод включить печь, а меняю ее свойство включена на значение true. Что произойдет в этот момент? Если принцип инкапсуляции не соблюден, то я буду вынужден печи сказать начинай потреблять горючее, т.к. я тебя включил. Т.е. пекарь знает, что печь потребляет горючее, знает, как печь работает. Или, например, мы не можем установить температуру печи ниже или выше определенного уровня. Если не соблюдать принцип инкапсуляции, то мы должны будем говорить печи проверь-ка текущую температуру, пойдет те такая? Т.е. пекарь опять слишком много знает о печи. Геттеры и сеттеры это средства языка, которые помогут нам легко реализовать отслеживание изменений состояния. Все. Если геттеры и сеттеры пустые, значит так надо на моем уровне абстракции. Геттеры и сеттеры — не могут мешать реализации инкапсуляции, криво реализовать инкапсуляцию может проектировщик/программист.

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

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

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

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

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

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

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

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

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

Понятие объектно-ориентированного программирования (ООП). Классы и объекты

Понятие объектно-ориентированное программирование (ООП) означает один из самых эффективных подходов к современному программированию.

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

Классы и объекты. В чем разница?

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

Пример

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

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

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

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

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

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

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

Все так запутано

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

PS. Не забываем подписываться на обновления по электронной почте в форме ниже!

Классы в ООП (Объектно-ориентированном программировании)

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

Понятие класса в ООП

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

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

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

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

Таким образом, наша банковская система состоит из экземпляров трех классов: класса счетов, класса банкоматов и класса клиентов. Названия классов в ООП пишутся с большой буквы, а названия объектов — с маленькой. Представленная ниже графическая схема классов соответствует обозначениям, принятым в Унифицированном языке моделирования UML.

Классы в учебной банковской системе

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

Разделение счетов на разные классы

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

Наследование классов в ООП

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

Механизм наследования классов в ООП позволяет выделить общие части разных классов. В приведенном выше примере, были выделены разные типы счетов в банковской системе. Однако они имеют много общего. Выделив общую часть, можно создать класс «Счет». Классы «Расчетный счет» и «Депозит» сохраняют все свойства (как методы, так и атрибуты) класса «Счет», дополняя и уточняя его поведение. Говорят что класс «Депозит» наследует класс «Счет». Графически это изображается в виде иерархии.

Схема наследования классов-счетов

Наследование классов в ООП может быть многоуровневым. Пример такой многоуровневой структуры классов-счетов представлен ниже.

Схема многоуровневого наследования классов

Иерархию классов в ООП можно построить по-разному. Фактически иерархия классов является классификатором объектов. В данном случае при построении системы классов разработчик пытается принять во внимание следующие соображения «Столь ли существенна разница между рублевыми и валютными вкладами, что их следует разделить на различные классы?», «Разные виды Депозитов — это разные характеристики одного и того же класса или же разные классы?» и т.п.

Как видно из рисунка, представленного выше, разница между рублевым и валютным счетом настолько существенна, что они выделены в разные классы. Разные виды Депозитов также представлены разными классами. Если бы решили, что денежная единица, в которой выражается сумма на счете, — лишь дополнительны атрибут счета, и разные типы депозитов различаются дополнительной характеристикой класса «Депозит», то иерархия классов преобразовалась бы к виду, изображенному на рисунке:

Упрощенная иерархия валютных и рублевых счетов

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

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

Рассмотренные до сих пор примеры показывали как класс в ООП может унаследовать методы и атрибуты одного базового класса. Такое наследование носит название одинарного или простого наследования. Наряду с ним существует и множественное наследование, при котором у одного класса имеется несколько базовых.

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

Множественное наследование

Класс «Валютный депозит» наследует атрибуты и методы обоих своих родителей.

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

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

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

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

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

Наследование, полиморфизм и отношения между классами в ООП

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

Использование наследования и полиморфизма в ООП

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

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

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

Приведем фрагмент кода программы на языке C++, который иллюстрирует использование базового класса «Фигура» для задания интерфейса. Ключевое слово class отмечает начало определения класса. В части, отмеченной меткой public, задается внешняя часть класса или его интерфейс. Ключевое слово virtual перед методом определяет то, что этот метод полиморфен (виртуален в терминах C++), т.е. может быть переопределен в порожденных классах. Все методы возвращают логический результат (bool), сообщающий об успешном или неуспешном завершении операции.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
// Базовый класс Фигура
// для него заданы методы, реализация которых
// отложена для выведенных классов
class Shape
{
public:
// Внешняя часть класса

    virtual bool Draw() = 0; // Перерисовать фигуру

    virtual bool Move(double _x, double _y) = 0; // Сдвинуть фигуру

    virtual bool Zoom(double scale) = 0; // Масштабировать
protected:

    // Защищенная часть класса, доступная только

    // выведенным из него классам

    double coordX; // Атрибут - координата X

    double coordY; // Атрибут - координата Y
};
// Класс Круг выведенный из класса Фигура
class Circle : public Shape
{
public:

    virtual bool Draw() {...}; // Реализация перерисовки

    virtual bool Move(double _x, double _y) {...}; // Реализация сдвига

    virtual bool Zoom(double scale) {...}; // Реализация операции масштабирования
private:

    // Внутренняя часть доступная только самому классу

    double radius; // Атрибут - длина радиуса
};
// Класс Квадрат выведенный из класса Фигура
class Square : public Shape
{
public:

    virtual bool Draw() {...}; // Реализация перерисовки

    virtual bool Move(double _x, double _y) {...}; // Реализация сдвига

    virtual bool Zoom(double scale) {...}; // Реализация операции масштабирования
private:

    // Внутренняя часть доступная только самому классу

    double side; // Атрибут - длина стороны квадрата
};
// Функция вызываемая в ответ на нажатие кнопки
// перерисовать весь экран
void click_ButtonRedraw()
{

    // Итерация по всем имеющимся фигурам

    while (Iterator it = listShapes.begin();

            it++;

            it != listShapes.end() ) {

                  // Используя указатель на базовый класс

                  // вызвать метод перерисовки конкретной фигуры
                  Shape* shapePtr = it.GetShape();

                  shapePtr->Draw();

    }
}

Отношения между классами в ООП

Включение

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

В данном случае используется включение по значению, т.е. у каждого автомобиля есть свой мотор, а у каждого мотора есть свой карбюратор. Если использовать язык C++ для записи классов, включение будет выглядеть так:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Carburetor    // Класс карбюраторов
{...}
class Engine    // Класс моторов
{
private:

    Carburetor engineCarburetor;  // Атрибут мотора - карбюратор
};
class Cars    // Класс автомобилей
{
private:

    Engine carEngine;  // Атрибут машина - мотор
};

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

Отношение включение может использовать ссылку на другой класс, т.е. использовать вместо объекта указатель ссылку на объект в языке C++:Engine* carEngine;

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

Ассоциация

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

Ассоциация «Руководитель — руководит» преподавателя и студентов

Ассоциация — двусторонняя ссылка, при каждом изменении ассоциации изменяются атрибуты обоих объектов. Говорят о множественности ассоциации, т.е. о количестве объектов, участвующих в ней. В примере преподаватели-студенты множественность ассоциации 1-n (один преподаватель может руководить несколькими студентами, у студента может быть только один руководитель). Легко представить себе ассоциации с множественностью 1-1, n-m и т.д.

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

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

Наследование выражает отношение «частное — общее» между классами. Базовый класс — это более общее понятие, которое уточняется в наследуемых классах. Базовый класс можно рассматривать как более высокий уровень абстракции по сравнению с выделенным из него классом.

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

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

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

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

Использование

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

Вызов методов другого класса также является отношением использования. Фактически при этом отношении один класс «знает» о существовании второго и «знает» по крайней мере его интерфейс.

Метаклассы и метаданные в ООП

Сказав, что классы в ООП создают шаблон для создания объектов, не было сказано, как же именно новые объекты создаются.

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

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

В языке C++ понятие метаклассов и метаобъектов отсутствует, однако фактически конструкторы классов и статические элементы классов относятся к функциональности метаклассов. Метаклассы реализованы в таких языках программирования, как Smalltalk, CLOS и других. Имея метаклассы, можно динамически, т.е в ходе выполнения программ, создавать новые классы, изменять существующие, добавляя или модифицируя элементы классов.

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

Операторы объекта — Blender Python API

тип ( перечисление в [ ‘DATA_TRANSFER’ , ‘MESH_CACHE’ , 000 ‘0005000 000500050005_MESH_SEQUENCE 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000/ , ‘WEIGHTED_NORMAL’ , ‘UV_PROJECT’ , ‘UV_WARP’ , ‘VERTEX_WEIGHT_EDIT’ 000, _ ‘VERT_PROJECT , _ ‘ VERT_PROJECT _ ‘ARRAY’ , ‘BEVEL’ , ‘BOOLEAN’ , ‘BUILD’ , ‘DECIMATE’ , IT EDGE IT EDGE МАСКА ‘ , ‘ ЗЕРКАЛО ‘ , ‘ MULTIRES ‘ , ‘ REMESH ‘ , ‘ ВИНТ ‘ , 9 0005 ‘SKIN’ , ‘SOLIDIFY’ , ‘SUBSURF’ , ‘TRIANGULATE’ , ‘WELD’ AME ‘ RAME’ ARMATURE ‘ , ‘ CAST ‘ , ‘ CURVE ‘ , ‘ DISPLACE ‘ , ‘ HOOK ‘ , ‘ LAPLACI , ‘MESH_DEFORM’ , ‘SHRINKWRAP’ , ‘SIMPLE_DEFORM’ , ‘SMOOTH’ 000 ‘ ‘ SMOOTH ‘ , ‘ SMOOTH ‘ , , ‘SURFACE_DEFORM’ , ‘WARP’ , ‘WAVE’ , ‘CLOTH’ , ‘COLLISION’ _PROLLISION ‘ _P 005, ‘EXPLODE’ ​​ , ‘FLUID’ , ‘OCEAN’ , ‘PARTICLE_INSTANCE’ , ‘PARTICLE_SYSTEM 0005 0005 0005 ‘SURFACE’ , ‘SIMULATION’ ] , ( опционально ) ) —

.

Операторы объектов — Blender 2.78.0 e8299c8

.

Операторы объектов — Blender 2.79.0 855d2955c49

.

Операторы объектов — Blender 2.76.0 a3cf9c5

.