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

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

Уровень и квалификация

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

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

Формы полиморфизма ООП, идеи инкапсуляции кода и наследование свойств (методов) лежат в сфере программирования, но никак не в сфере решаемой задачи.

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

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

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

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

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

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

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

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

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

Популярные определения полиморфизма

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

1. Полиморфизм в программировании - это способность предоставлять один и тот же интерфейс для различных базовых форм (типов данных).
2. Полиморфизм - возможность объектов иметь различную реализацию.
3. Полиморфизмом называется способность функции...
4. Классика (от создателя С/С++): «один интерфейс - много реализаций».
5. Параметрический полиморфизм подразумевает...
6. Полиморфизм - положение теории типов...
7. Абстракция невозможна без инкапсуляции и наследования, как невозможен полиморфизм без наследования...

Можно согласиться, что всё это относится к одному и тому же: но форма выражения мысли, сущность и содержание - не подобны. Но что-то общее всё же есть.

Сущность: разработчик - заказчик

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

Такой круговорот процесса решения задачи наводит на мысль, что здесь явно совмещены две совершенно разные сущности:

• компьютер не может сам решить задачу;
• нужна программа, чтобы компьютер мог «понять» и «решить» задачу.

Задача - сфера компетенции заказчика, программа - это алгоритм «адаптации» задачи к возможностям компьютера - сфера компетенции программиста. Роль последнего заключается в «адаптации» компьютера к требованиям задачи, а это лишнее!

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

Окна, кнопки и другие объекты

История the Air Art Technology, Object Magazine, Turbo Vision, Graph Vision - это уже история. Мало кто помнит эти реализации ООП, они практически не используются и забыты, но оконный интерфейс Windows знаком миллионам пользователей, а объекты в средах PHP, JavaScript и других языках интернет-технологий применяются сотнями тысяч разработчиков кода, о них знают миллионы посетителей веб-ресурсов.

Вероятно, это единственно правильный путь, по которому должно было развиваться ООП: инкапсуляция, наследование, полиморфизм для разработчика, но не для пользователя. Характерно, что именно эта позиция была основной при разработке визуального оформления (интерфейса) программного обеспечения Windows, прикладных программ типа Turbo Vision и Graph Vision.

Концепция, положенная в основу продуктов типа the Air Art Technology и Object Magazine, существенно отличалась. Здесь абстрактный объект был самым первым предком информационной структуры, инкапсулировал на абстрактном уровне код обработки информации. Объекты окон, кнопок, элементов визуального оформления здесь были вторичны.

В первом варианте (Windows & etc.) парадигма ООП: инкапсуляция, наследование, полиморфизм обозначалась на уровне абстрактного предка, а реализация кода формировалась на уровне каждого конкретного потомка по ветке наследования согласно нужным структуре и содержанию.

Во втором варианте (the Air Art Technology и Object Magazine) важен уровень абстрактного объекта. Что будет у конкретного потомка - не суть, главное, чтобы его ветка наследования удовлетворяла требованиям всех родителей вниз до корневой абстракции.

Объект и система объектов: алгоритм

Идеальная объектно-ориентированная концепция может манипулировать только объектами и системами объектов.

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

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

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

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

Объект и система объектов: задача и решение

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

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

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

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

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

Традиционное и объектное программирование

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

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

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

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

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

Что в основе: объект или система

Абстракция, как основное концептуальное положение ООП, вне зависимости от того, где находится зона ответственности (реализация) объекта - на уровне первого абстрактного объекта или на уровне конкретного потомка, - оставляет открытым вопрос: с чего всё начинать, с объекта или с системы?

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

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

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

Но это и подобное ему не даёт никаких оснований ставить в основу решения задачи систему объектов. Часто достаточно определить один единственный начальный объект.

История процесса решения задачи

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

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

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

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

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

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

Реальный полиморфизм ООП, пример

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

Не так давно была разработана библиотека PHPOffice/PHPWord, но для того чтобы использовать её возможности, практически всегда приходится создавать собственную систему объектов. Например, простой файл *.docx:

представляет собой zip-архив множества файлов и папок в формате Office Open XML (OpenXML, OOXML). Каждый файл записан в тегами XML, причём при добавлении, изменении и удалении букв, слов, таблиц, списков и пр. элементов содержимое файлов начинает представлять собой последовательность тегов, которые не всегда содержат полные элементы, часто один элемент записывается множеством тегов.

Если представить этот файл в виде последовательности тегов, получится интересная картинка:

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

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

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

Состояние области ООП

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

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

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

Перспективы объектной идеи

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

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

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

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

Виды полиморфизма:

Статический (определяется во время компиляции). Перегрузка функций, методов, операторов и т.д.

Динамический (определяется во время выполнения). Содержит виртуальные функции и методы.

22. Наследование как механизм реализации полиморфизма, создания иерархий классов. Типы наследования.

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

Типы наследования: прямое и косвенное, простое и множественное.

23. Классы. Базовые, производные, полиморфные, абстрактные, виртуаль-ные. Примеры.

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

Базовый класс – класс, члены которого наследуются.

Производный класс – класс, который наследует чужие члены.

Полиморфный класс – класс, содержащий виртуальные методы.

Абстрактный класс – класс, содержащий чисто виртуальные методы.

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

24. Принципы раннего и позднего связывания.

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

Ранее связывание - установка таких связей до начала выполнения программы. Обычно под этим понимается связывание в процессе компиляции исходных модулей и компоновки исполняемого модуля из объектных.

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

25. Использование языка uml для спецификации

26. Описание иерархий классов диаграммами uml.

Отношения классов через . И показать разные отношения: прямое, косвенное, множественное.

27. Классы-шаблоны. Описание в uml.

Шабло́н класса - средство языка C++, предназначенное для кодирования обобщённых алгоритмов классов, без привязки к некоторым параметрам (например, типам данных, размерам буферов, значениям по умолчанию).

Синтаксис:

template

class NAME_CLASS

NAME_CLASS B; //Вызов

Привет! Это статья об одном из принципов ООП - полиморфизм.

Что такое полиморфизм

Определение полиморфизма звучит устрашающе 🙂

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

Слово "полиморфизм " может показаться сложным - но это не так. Нужно просто разбить данное определение на части и показать на примерах, что имеется в виду. Поверьте, уже в конце статьи данное определение полиморфизма покажется Вам понятным 🙂

Полиморфизм , если перевести, - это значит "много форм". Например, актер в театре может примерять на себя много ролей - или принимать "много форм".

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

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

Как проявляется полиморфизм

Дело в том, что если бы в Java не было принципа полиморфизма , компилятор бы интерпретировал это как ошибку:

Как видите, методы на картинке отличаются значениями, которые они принимают:

• первый принимает int
• а второй принимает String

Однако, поскольку в Java используется принцип полиморфизма, компилятор не будет воспринимать это как ошибку, потому что такие методы будут считаться разными :

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

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

Теперь Вы можете понять, почему часто этот принцип описывают фразой:

Один интерфейс - много методов

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

Перегрузка методов

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

Переопределение методов родителя

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

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

Пример

Представим, что у нас есть такая структура:

Вверху иерархии классов стоит класс Animal . Его наследуют три класса - Cat , Dog и Cow .

У класса "Animal" есть метод "голос" (voice). Этот метод выводит на экран сообщение "Голос". Естественно, ни собака, ни кошка не говорят "Голос" 🙂 Они гавкают и мяукают. Соответственно, Вам нужно задать другой метод для классов Cat , Dog и Cow - чтобы кошка мяукала, собака гавкала, а корова говорила "Муу".

Поэтому, в классах-наследниках мы переопределяем метод voice() , чтобы мы в консоли получали "Мяу", "Гав" и "Муу".

• Обратите внимание: перед методом, который мы переопределяем, пишем "@Override ". Это дает понять компилятору, что мы хотим переопределить метод.

Так что же такое полиморфизм

Тем не менее, полиморфизм - это принцип. Все реальные примеры, которые мы приведодили выше - это только способы реализации полиморфизма.

Давайте снова посмотрим на определение, которое мы давали в начале статьи:

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

Выглядит понятнее, правда? Мы показали, как можно:

• создавать "одноименные методы" в одном классе ("перегрузка методов")
• или изменить поведение методов родительского класса ("переопределение методов").

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

Надеемся, наша статья была Вам полезна. Записаться на наши курсы по Java можно у нас на .

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

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

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

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

Наследование является неотъемлемой частью Java. При использовании наследования принимается во внимание, что новый класс, наследующий свойства базового (родительского) класса имеет все те свойства, которым обладает родитель. В коде используется операнд extends , после которого указывается имя базового класса. Тем самым открывается доступ ко всем полям и методам базового класса.

Используя наследование, можно создать общий "java class", который определяет характеристики, общие для набора связанных элементов. Затем можно наследоваться от него и создать дополнительные классы, для которых определить дополнительные уникальные для них характеристики.

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

Рассмотрим пример описания java class"a студента Student, который имеет имя, фамилию, возраст, и номер группы. Класс студента будем создавать на основе super класса пользователя User, у которого уже определены имя, фамилия и возраст:

Public class User { int age; String firstName; String lastName; // Конструктор public User(int age, String firstName, String lastName) { this.age = age; this.firstName = firstName; this.lastName = lastName; } }

Теперь создаем отдельный класс Student, наследующего свойства super класса. При наследовании класса необходимо также переопределить и конструкторы родительского класса:

Public class Student extends User { int group; // Конструктор public Student(int age, String firstName, String lastName) { super(age, firstName, lastName); } boolean isMyGroup(int g) { return g == group; } }

Ключевое слово extends показывает, что мы наследуемся от класса User.

Ключевое слово super

В конструкторе класса Student мы вызываем конструктор родительского класса через оператор super , передавая ему весь необходимой набор параметров. В Java ключевое слово super обозначает суперкласс, т.е. класс, производным от которого является текущий класс. Ключевое слово super можно использовать для вызова конструктора суперкласса и для обращения к члену суперкласса, скрытому членом подкласса.

Рассмотрим как происходит наследование с точки зрения создания объекта:

Student student = new Student(18, "Киса", "Воробьянинов", 221);

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

У суперкласса могут быть несколько перегруженных версий конструкторов, поэтому можно вызывать метод super() с разными параметрами. Программа выполнит тот конструктор, который соответствует указанным аргументам.

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

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

Class A { int i; } // наследуемся от класса A class B extends A { int i; // имя переменной совпадает и скрывает переменную i в классе A B(int a, int b) { super.i = a; // обращаемся к переменной i из класса A i = b; // обращаемся к переменной i из класса B } void show() { System.out.println("i из суперкласса равно " + super.i); System.out.println("i в подклассе равно " + i); } } class MainActivity { B subClass = new B(1, 2); subClass.show(); }

В результате в консоли мы должны увидеть:

I из суперкласса равно 1 i в подклассе равно 2

Переопределение методов, Override

Если в иерархии классов имя и сигнатура типа метода подкласса совпадает с атрибутами метода суперкласса, то метод подкласса переопределяет метод суперкласса. Когда переопределённый метод вызывается из своего подкласса, он всегда будет ссылаться на версию этого метода, определённую подклассом. А версия метода из суперкласса будет скрыта.

Если нужно получить доступ к версии переопределённого метода, определённого в суперклассе, то необходимо использовать ключевое слово super .

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

В Java SE5 появилась анотация @Override; . Если необходимо переопределить метод, то используйте @Override, и компилятор выдаст сообщение об ошибке, если вместо переопределения будет случайно выполнена перегрузка.

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

В информатике инкапсуляцией (лат. en capsula) называется упаковка данных и/или функций в единый объект.

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

Модификаторы доступа

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

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

Желательно использовать доступ к свойствам класса только через его методы (принцип bean классов, "POJO"), который позволяет валидировать значения полей, так как прямое обращение к свойствам отслеживать крайне сложно, а значит им могут присваиваться некорректные значения на этапе выполнения программы. Такой принцип относится к управлению инкапсулированными данными и позволяет быстро изменить способ хранения данных. Если данные станут храниться не в памяти, а в файлах или базе данных, то потребуется изменить лишь ряд методов одного класса, а не вводить эту функциональность во все части системы.

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

Пример простого описания робота

Public class Robot { private double x = 0; // Текущая координата X private double y = 0; // Текущая координата Y private double course = 0; // Текущий курс (в градусах) public double getX() { return x; } public void setX(double x) { this.x = x; } public double getY() { return y; } public void setY(double y) { this.y = y; } public double getCourse() { return course; } // Определение курса public void setCourse(double course) { this.course = course; } // Передвижение на дистанцию distance public void forward(int distance) { // Обращение к полю объекта X x = x + distance * Math.cos(course / 180 * Math.PI); // Обращение к полю объекта Y y = y + distance * Math.sin(course / 180 * Math.PI); } // Печать координат робота public void printCoordinates() { System.out.println(x + "," + y); } }

В представленном примере робота используются наборы методов, начинающие с set и get . Эту пару методов часто называют сеттер/геттер. Данные методы используются для доступа к полям объекта. Наименования метода заканчиваются наименованием поля, начинающееся с ПРОПИСНОЙ буквы.

В методах set мы передаем значение через формальный параметр во внутрь процедуры. В коде процедуры мы присваиваем значение переменной объекта/класса с использованием ключевого слова this .

This.course = course ...

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

Полиморфизм, polymorphism

Полиморфизм является одним из фундаментальных понятий в объектно-ориентированном программировании наряду с наследованием и инкапсуляцией. Слово полиморфизм греческого происхождения и означает "имеющий много форм". Чтобы понять, что означает полиморфизм применительно к объектно-ориентированному программированию, рассмотрим пример создания векторного графического редактора, в котором необходимо использовать ряд классов в виде набора графических примитивов - Square , Line , Circle , Triangle , и т.д. У каждого из этих классов необходимо определить метод draw для отображения соответствующего примитива на экране.

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

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

// Определение массивов графических примитивов Square s = new Square ; Line l = new Line ; Circle c = new Circle ; Triangle t = new Triangle; // Заполнение всех массивов соответствующими объектами. . . // Цикл с перебором всех ячеек массива. for (int i = 0; i < s.length; i++){ // вызов метода draw() в случае, если ячейка не пустая. if (s[i] != null) s.draw(); } for(int i = 0; i < l.length; i++){ if (l[i] != null) l.draw(); } for(int i = 0; i < c.length; i++){ if (c[i] != null) c.draw(); } for(int i = 0; i < t.length; i++){ if (t[i] != null) t.draw(); }

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

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

Public class Shape { public void draw() { System.out.println("Заглушка"); } }

После этого мы создаем различные классы-наследники: Square (Квадрат), Line (Линия), Сircle (круг) и Triangle (Треугольник):

Public class Point extends Shape { public void draw() { System.out.println("Квадрат"); } } public class Line extends Shape { public void draw() { System.out.println("Линия"); } } public class Сircle extends Shape { public void draw() { System.out.println("Круг"); } } public class Triangle extends Shape { public void draw() { System.out.println("Треугольник"); } }

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

Теперь проверим удивительную возможность полиморфизма:

// Определение и инициализация массива Shape a = new Shape {new Shape(), new Triangle(), new Square(), new Сircle()}; // Перебор в цикле элементов массива for(int i = 0; i < a.length; i++) { a[i].draw(); }

В консоль будут выведены следующие строки:

Заглушка Треугольник Квадрат Круг

Таким образом каждый класс-наследник вызвал именно свой метод draw, вместо того, чтобы вызвать метод draw из родительского класса Shape.

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

Перегрузка метода, overload

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

Void println() // переход на новую строку void println(boolean x) // выводит значение булевской переменной (true или false) void println(String x) // выводит строку - значение текстового параметра

s_a_p 20 августа 2008 в 19:09

Полиморфизм для начинающих

• PHP

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

Постановка задачи

Самые простые варианты, которые приходят в голову — написать три отдельных класса и работать с ними. Или написать один класс, в которым будут все свойства, присущие всем трем типам публикаций, а задействоваться будут только нужные. Но ведь для разных типов аналогичные по логике методы должны работать по-разному. Делать несколько однотипных методов для разных типов (get_news, get_announcements, get_articles) — это уже совсем неграмотно. Тут нам и поможет полиморфизм.

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

abstract class Publication
{
// таблица, в которой хранятся данные по элементу
protected $table ;

// свойства элемента нам неизвестны
protected $properties = array();

// конструктор

{
// обратите внимание, мы не знаем, из какой таблицы нам нужно получить данные
$result = mysql_query ("SELECT * FROM `" . $this -> table . "` WHERE `id`="" . $id . "" LIMIT 1" );
// какие мы получили данные, мы тоже не знаем
$this -> properties = mysql_fetch_assoc ($result );
}

// метод, одинаковый для любого типа публикаций, возвращает значение свойства
public function get_property ($name )
{
if (isset($this -> properties [ $name ]))
return $this -> properties [ $name ];

Return false ;
}

// метод, одинаковый для любого типа публикаций, устанавливает значение свойства
public function set_property ($name , $value )
{
if (!isset($this -> properties [ $name ]))
return false ;

$this -> properties [ $name ] = $value ;

Return $value ;
}

// а этот метод должен напечатать публикацию, но мы не знаем, как именно это сделать, и потому объявляем его абстрактным
abstract public function do_print ();
}

Производные классы

class News extends Publication
{
// конструктор класса новостей, производного от класса публикаций
public function __construct ($id )
{
// устанавливаем значение таблицы, в которой хранятся данные по новостям
$this -> table = "news_table" ;
parent :: __construct ($id );
}

Public function do_print ()
{
echo $this -> properties [ "title" ];
echo "

" ;
echo $this -> properties [ "text" ];
echo "
Источник: " . $this -> properties [ "source" ];
}
}

Class Announcement extends Publication
{
// конструктор класса объявлений, производного от класса публикаций
public function __construct ($id )
{
// устанавливаем значение таблицы, в которой хранятся данные по объявлениям
$this -> table = "announcements_table" ;
// вызываем конструктор родительского класса
parent :: __construct ($id );
}

// переопределяем абстрактный метод печати
public function do_print ()
{
echo $this -> properties [ "title" ];
echo "
Внимание! Объявление действительно до " . $this -> properties [ "end_date" ];
echo "

" . $this -> properties [ "text" ];
}
}

Class Article extends Publication
{
// конструктор класса статей, производного от класса публикаций
public function __construct ($id )
{
// устанавливаем значение таблицы, в которой хранятся данные по статьям
$this -> table = "articles_table" ;
// вызываем конструктор родительского класса
parent :: __construct ($id );
}

// переопределяем абстрактный метод печати
public function do_print ()
{
echo $this -> properties [ "title" ];
echo "

" ;
echo $this -> properties [ "text" ];
echo "
" . $this -> properties [ "author" ];
}
}

Теперь об использовании

// наполняем массив публикаций объектами, производными от Publication
$publications = new News ($news_id );
$publications = new Announcement ($announcement_id );
$publications = new Article ($article_id );

Foreach ($publications as $publication ) {
// если мы работаем с наследниками Publication
if ($publication instanceof Publication ) {
// то печатаем данные
$publication -> do_print ();
} else {
// исключение или обработка ошибки
}
}

Вот и все. Легким движением руки брюки превращаются в элегантные шорты:-).

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

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

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