Что такое делегация java

Pro Java

Страницы

2 июл. 2015 г.

Делегирование.

А сейчас рассмотрим на простом примере что же это за зверь такой – делегирование.

Например, класс SpaceShipControls имитирует модуль управления космическим кораблем. А Для построения космического корабля можно воспользоваться наследованием в классе SpaceShip.

Что такое делегация java. Смотреть фото Что такое делегация java. Смотреть картинку Что такое делегация java. Картинка про Что такое делегация java. Фото Что такое делегация java

Что такое делегация java. Смотреть фото Что такое делегация java. Смотреть картинку Что такое делегация java. Картинка про Что такое делегация java. Фото Что такое делегация java

Однако космический корабль не может рассматриваться как частный случай своего управляющего модуля — несмотря на то, что ему, к примеру, можно приказать двигаться вперед (forward()). Точнее сказать, что SpaceShip содержит SpaceShipControls, и в то же время все методы последнего предоставляются классом SpaceShip. Проблема решается при помощи делегирования:

Что такое делегация java. Смотреть фото Что такое делегация java. Смотреть картинку Что такое делегация java. Картинка про Что такое делегация java. Фото Что такое делегация java

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

Источник

BestProg

Содержание

Поиск на других ресурсах:

1. Каким образом повторное использование кода применяется в классах?

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

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

2. Какие существуют способы (подходы) построения классов для эффективного обеспечения повторного использования кода?

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

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

Эти способы еще называют отношениями между классами. Во всех способах строятся новые классы (типы) на базе уже существующих классов (типов).

3. Примеры композиции в классах
4. Какая общая форма простейшего наследования классом другого класса. Ключевое слово extends
5. Примеры наследования в классах
6. Пример объединения композиции и наследования

На примере объявления трех классов демонстрируется объединение композиции и наследования.

Что такое делегация java. Смотреть фото Что такое делегация java. Смотреть картинку Что такое делегация java. Картинка про Что такое делегация java. Фото Что такое делегация java

Рисунок. Схема объединения композиции и наследования для трех классов

Исходный код модуля с разработанными классами.

7. Особенности делегирования по сравнению с наследованием и композицией. Пример

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

После такого переопределения обращение к методу MethodA() класса B будет выглядеть так если бы MethodA() был унаследован:

Такая организация отношения между классами называется делегированием. Метод MethodA() класса B называется делегированным методом.

8. Какие отличия между композицией и наследованием?

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

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

Наследование позволяет расширять возможности нового класса с точки зрения его специализации. Это значит, что создается специализированная версия уже существующего класса. То есть, берется уже существующий класс (базовый класс) и создается его новая специализированная версия. Как правило, в роли базового класса выступает некий класс общего назначения, в котором выделены общие черты задачи. Наследованием выражает взаимосвязь is-a («есть» или «является»).

Композиция используется, когда нужно использовать функциональность уже существующего класса в другом (новосозданном) классе. В этом случае в новосозданном классе объявляется объект класса, функциональность которого нужно использовать. Композиция является одним из видов взаимосвязи has-a (клас «содержит»).

Объект класса в другом классе может быть скрытым ( private ), открытым ( public ) или защищенным ( protected ).

Источник

Различение между делегированием, композицией и агрегацией (Java OO Design)

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

Я консультировался с Java Oo Analysis and Design book, но моя путаница все еще остается. Основное объяснение заключается в следующем:

делегация: когда мой объект использует функции другого объекта как есть, не изменяя его.

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

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

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

4 ответов:

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

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

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

Делегация: Ваш босс попросил тебя принести ему кофе, но вместо этого ты попросил интерна сделать это за тебя. Делегирование не является типом ассоциации (как композиция / агрегация). Последние два были обсуждены на Stack Overflow много раз

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

но различия заключаются в жизненном цикле и мощности связанных объектов.

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

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

в случае делегирования у вас может даже не быть переменной-члена для хранения делегата

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

делегация

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

гибрид Делегация

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

состав

еще раз никаких ссылок на конкретный экземпляр класса A существует, его экземпляр класса B разрушен.

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

агрегация

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

Демонстрация Без Ссылок

имена, данные этим простым шаблонам, определяются их ссылочными отношениями.

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

делегация: когда мой объект использует функции другого объекта как есть, не изменяя его.

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

из выше например, большой.функция () вызов функции FH как есть без ее изменения. Таким образом, класс Big не должен содержать реализацию функции (разделение труда). Кроме того, feature() может реализовываться по-разному другим классом, например «NewFeatureHolder», и Big может вместо этого использовать новый держатель функции.

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

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

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

извините за мой английский, надеюсь, это поможет

1) делегирование: человек-водитель-пример автомобиля. Мужчина купил машину. Но этот человек не умеет водить машину. Поэтому он назначит водителя, который знает, как управлять автомобилем. Таким образом, класс Man хочет выполнить перевозку с использованием автомобиля. Но у него нет взаимодействующей функциональности / совместимости с автомобилем. Поэтому он использует класс, который имеет совместимость с автомобилем, который является драйвером, который совместим с классом man. Предполагая, что водитель может понять, что говорит человек

2) Состав: Автомобиль моделирование является обычным примером. Чтобы заставить автомобиль двигаться, колесо вращается. Класс автомобиля используя класс колеса вращает functinality как часть своей функции движения, где как колесо часть автомобиля.

3) агрегация: автомобиль и его цвет. Объект класса автомобиля ferrari будет иметь цвет объекта класса красный. Но объект класса цвета red может быть там как отдельный класс, когда поиск пользователя происходит со спецификацией красного цвета.

Источник

Делегирование событий

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

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

Рассмотрим пример – диаграмму Ба-Гуа. Это таблица, отражающая древнюю китайскую философию.

Её HTML (схематично):

В этой таблице всего 9 ячеек, но могло бы быть и 99, и даже 9999, не важно.

Наша задача – реализовать подсветку ячейки

при клике.

Вместо того, чтобы назначать обработчик onclick для каждой ячейки

(их может быть очень много) – мы повесим «единый» обработчик на элемент

.

Такому коду нет разницы, сколько ячеек в таблице. Мы можем добавлять, удалять

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

Однако, у текущей версии кода есть недостаток.

Клик может быть не на теге

, а внутри него.

В нашем случае, если взглянуть на HTML-код таблицы внимательно, видно, что ячейка

содержит вложенные теги, например :

Внутри обработчика table.onclick мы должны по event.target разобраться, был клик внутри

или нет.

Вот улучшенный код:

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

.

Применение делегирования: действия в разметке

Есть и другие применения делегирования.

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

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

Так что же даёт нам здесь делегирование?

Приём проектирования «поведение»

Делегирование событий можно использовать для добавления элементам «поведения» (behavior), декларативно задавая хитрые обработчики установкой специальных HTML-атрибутов и классов.

Приём проектирования «поведение» состоит из двух частей:

Поведение: «Счётчик»

Например, здесь HTML-атрибут data-counter добавляет кнопкам поведение: «увеличить значение при клике»:

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

Элементов с атрибутом data-counter может быть сколько угодно. Новые могут добавляться в HTML-код в любой момент. При помощи делегирования мы фактически добавили новый «псевдостандартный» атрибут в HTML, который добавляет элементу новую возможность («поведение»).

Поведение: «Переключатель» (Toggler)

Ещё один пример поведения. Сделаем так, что при клике на элемент с атрибутом data-toggle-id будет скрываться/показываться элемент с заданным id :

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

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

Шаблон «поведение» может служить альтернативой для фрагментов JS-кода в вёрстке.

Итого

Делегирование событий – это здорово! Пожалуй, это один из самых полезных приёмов для работы с DOM.

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

Конечно, у делегирования событий есть свои ограничения:

Задачи

Спрячьте сообщения с помощью делегирования

В результате должно работать вот так:

P.S. Используйте делегирование событий. Должен быть лишь один обработчик на элементе-контейнере для всего.

Раскрывающееся дерево

Создайте дерево, которое по клику на заголовок скрывает-показывает потомков:

Решение состоит из двух шагов:

Сортируемая таблица

Сделать таблицу сортируемой: при клике на элемент

строки таблицы должны сортироваться по соответствующему столбцу.

Каждый элемент

имеет атрибут data-type:

В примере выше первый столбец содержит числа, а второй – строки. Функция сортировки должна это учитывать, ведь числа сортируются иначе, чем строки.

P.S. Таблица может быть большой, с любым числом строк и столбцов.

Поведение «подсказка»

Напишите JS-код, реализующий поведение «подсказка».

Пример HTML с подсказками:

Результат в ифрейме с документом:

В этой задаче мы полагаем, что во всех элементах с атрибутом data-tooltip – только текст. То есть, в них нет вложенных тегов (пока).

Для решения вам понадобятся два события:

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

Источник

Вільні програми
на Java

Додати програму

Категорії

Пошук програм

Что такое делегация java. Смотреть фото Что такое делегация java. Смотреть картинку Что такое делегация java. Картинка про Что такое делегация java. Фото Что такое делегация java
Рекламки:

Глава 7 Thinking in Java 4th edition

ПОВТОРНОЕ ИСПОЛЬЗОВАНИЕ КЛАССОВ

Содержание

ПОВТОРНОЕ ИСПОЛЬЗОВАНИЕ КЛАССОВ

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

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

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

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

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

Синтаксис композиции

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

В обоих классах определяется особый метод toString(). Позже вы узнаете, что каждый не-примитивный объект имеет метод toString(), который вызывается в специальных случаях, когда компилятор располагает не объектом, а хочет получить его строковое представление в формате String. Поэтому в выражении из метода SрrinklerSystem.toString ():

компилятор видит, что к строке «source = « «прибавляется» объект класса WaterSource. Компилятор не может это сделать, поскольку к строке можно «добавить» только такую же строку, поэтому он преобразует объект source в String, вызывая метод toString(). После этого компилятор уже в состоянии соединить две строки и передать результат в метод System.out.println() (или статическим методам print() и printnb(), используемым в книге). Чтобы подобное поведение поддерживалось вашим классом, достаточно включить в него метод toString().

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

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

В следующем примере продемонстрированы все четыре способа:

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

Синтаксис наследования

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

Синтаксис композиции очевиден, но для наследования существует совершенно другая форма записи. При использовании наследования вы фактически говорите: «Этот новый класс похож на тот старый класс». В программе этот факт выражается перед фигурной скобкой, открывающей тело класса: сначала записывается ключевое слово extends, а затем имя базового (base) класса. Тем самым вы автоматически получаете доступ ко всем полям и методам базового класса. Пример:

Пример демонстрирует сразу несколько особенностей наследования. Во-первых, в методе класса Cleanser.append() новые строки присоединяются к строке s оператором +=, одним из операторов, специально «перегруженных» создателями Java для строк (String).

Во-вторых, как Cleanser, так и Detergent содержат метод main(). Вы можете определить метод main() в каждом из своих классов; это позволяет встраивать тестовый код прямо в класс. Метод main() даже не обязательно удалять после завершения тестирования, его вполне можно оставить на будущее.

Даже если у вас в программе имеется множество классов, из командной строки исполняется только один (так как метод main() всегда объявляется как public, то неважно, объявлен ли класс, в котором он описан, как public). В нашем примере команда java Detergent вызывает метод Detergent.main(). Однако вы также можете использовать команду java Cleanser для вызова метода Cleanser.main(), хотя класс Cleanser не объявлен открытым. Даже если класс обладает доступом в пределах класса, открытый метод main() остается доступным.

Здесь метод Detergent.main() вызывает Cleanser.main() явно, передавая ему собственный массив аргументов командной строки (впрочем, для этого годится любой массив строк).

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

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

Класс Cleanser содержит ряд методов: append(), dilute(), apply(), scrub() и toString(). Так как класс Detergent произведен от класса Cleanser (с помощью ключевого слова extends), он автоматически получает все эти методы в своем интерфейсе, хотя они и не определяются явно в классе Detergent. Таким образом, наследование обеспечивает повторное использование класса.

Как показано на примере метода scrub(), разработчик может взять уже существующий метод базового класса и изменить его. Возможно, в этом случае потребуется вызвать метод базового класса из новой версии этого метода. Однако в методе scrub() вы не можете просто вызвать scrub() — это приведет к рекурсии, а нам нужно не это. Для решения проблемы в Java существует ключевое слово super, которое обозначает «суперкласс», то есть класс, производным от которого является текущий класс. Таким образом, выражение super.scrub() обращается к методу scrub() из базового класса.

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

В методе Detergent.main() для объекта класса Detergent вызываются все методы, доступные как из класса Cleanser, так и из класса Detergent (имеется в виду метод foam()).

Инициализация базового класса

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

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

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

Конструкторы с аргументами

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

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

Делегирование

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

Для построения космического корабля можно воспользоваться наследованием:

Однако космический корабль не может рассматриваться как частный случай своего управляющего модуля — несмотря на то, что ему, к примеру, можно приказать двигаться вперед (forward()). Точнее сказать, что SpaceShip содержит SpaceShipControls, и в то же время все методы последнего предоставляются классом SpaceShip. Проблема решается при помощи делегирования:

Как видите, вызовы методов переадресуются встроенному объекту controls, а интерфейс остается таким же, как и при наследовании. С другой стороны, делегирование позволяет лучше управлять происходящим, потому что вы можете ограничиться небольшим подмножеством методов встроенного объекта.
Хотя делегирование не поддерживается языком Java, его поддержка присутствует во многих средах разработки. Например, приведенный пример был автоматически сгенерирован в JetBrains Idea IDE.

Сочетание композиции и наследования

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

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

Обеспечение правильного завершения

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

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

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

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

В методе main() вы можете заметить два новых ключевых слова, которые будут подробно рассмотрены в главе 10: try и finally. Ключевое слово try показывает, что следующий за ним блок (ограниченный фигурными скобками) является защищенной секцией. Код в секции finally выполняется всегда, независимо от того, как прошло выполнение блока try. (При обработке исключений можно выйти из блока try некоторыми необычными способами.) В данном примере секция finally означает: «Что бы ни произошло, в конце всегда вызывать метод x.dispose()».

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

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

Сокрытие имен

Если какой-либо из методов базового класса Java был перегружен несколько раз, переопределение имени этого метода в производном классе не скроет ни одну из базовых версий (в отличие от C++). Поэтому перегрузка работает вне зависимости от того, где был определен метод — на текущем уровне или в базовом классе:

Мы видим, что все перегруженные методы класса Homer доступны классу Bart, хотя класс Bart и добавляет новый перегруженный метод (в C++ такое действие спрятало бы все методы базового класса). Как вы увидите в следующей главе, на практике при переопределении методов гораздо чаще используется точно такое же описание и список аргументов, как и в базовом классе. Иначе легко можно запутаться (и поэтому C++ запрещает это, чтобы предотвратить совершение возможной ошибки).

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

Композиция в сравнении с наследованием

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

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

Иногда требуется предоставить пользователю прямой доступ к композиции вашего класса, то есть сделать встроенный объект открытым (public). Встроенные объекты и сами используют сокрытие реализации, поэтому открытый доступ безопасен. Когда пользователь знает, что класс собирается из составных частей, ему значительно легче понять его интерфейс. Хорошим примером служит объект Саr (машина):

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

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

protected

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

Ключевое слово protected — дань прагматизму. Оно означает: «Член класса является закрытым (private) для пользователя класса, но для всех, кто наследует от класса, и для соседей по пакету он доступен». (В Java protected автоматически предоставляет доступ в пределах пакета.)

Лучше всего, конечно, объявлять поля класса как private — всегда стоит оставить за собою право изменять лежащую в основе реализацию. Управляемый доступ наследникам класса предоставляется через методы protected:

Как видите, метод change() имеет доступ к методу set(), поскольку тот объявлен как protected. Также обратите внимание, что метод toString() класса Orс определяется с использованием версии этого метода из базового класса.

Восходящее преобразование типов

Данная формулировка — не просто причудливый способ описания наследования, она напрямую поддерживается языком. В качестве примера рассмотрим базовый класс с именем Instrument для представления музыкальных инструментов и его производный класс Wind. Так как наследование означает, что все методы базового класса также доступны в производном классе, любое сообщение, которое вы в состоянии отправить базовому классу, можно отправить и производному классу.

Если в классе Instrument имеется метод play(), то он будет присутствовать и в классе Wind. Таким образом, мы можем со всей определенностью утверждать, что объекты Wind также имеют тип Instrument. Следующий пример показывает, как компилятор поддерживает такое понятие:

Наибольший интерес в этом примере представляет метод tune(), получающий ссылку на объект Instrument. Однако в методе Wind.main() методу tune() передается ссылка на объект Wind. С учетом всего, что говорилось о строгой проверке типов в Java, кажется странным, что метод с готовностью берет один тип вместо другого. Но стоит вспомнить, что объект Wind также является объектом Instrument, и не существует метода, который можно вызвать в методе tune() для объектов Instrument, но нельзя для объектов Wind. В методе tune() код работает для Instrument и любых объектов, производных от Instrument, а преобразование ссылки на объект Wind в ссылку на объект Instrument называется восходящим преобразованием типов (upcasting).

Почему «восходящее преобразование»?

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

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

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

Преобразование также может выполняться и в обратном направлении — так называемое нисходящее преобразование (downcasting). Но при этом возникает проблема, которая рассматривается в главе 1.1.

Снова о композиции с наследованием

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

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

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

Неизменные данные

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

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

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

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

Следующий пример демонстрирует использование final для полей классов:

Так как valueOne и VALUE_TWO являются примитивными типами со значениями, заданными на стадии компиляции, они оба могут использоваться в качестве констант времени компиляции, и принципиальных различий между ними нет. Константа VALUE_THREE демонстрирует общепринятый способ определения подобных полей: спецификатор public открывает к ней доступ за пределами пакета; ключевое слово static указывает, что она существует в единственном числе, а ключевое слово final указывает, что ее значение остается неизменным. Заметьте, что примитивы final static с неизменными начальными значениями (то есть константы времени компиляции) записываются целиком заглавными буквами, а слова разделяются подчеркиванием (эта схема записи констант позаимствована из языка C).

Само по себе присутствие final еще не означает, что значение переменной известно уже на стадии компиляции. Данный факт продемонстрирован на примере инициализации І4 и INT_5 с использованием случайных чисел. Эта часть про­граммы также показывает разницу между статическими и нестатическими константами. Она проявляется только при инициализации во время исполнения, так как все величины времени компиляции обрабатываются компилятором одинаково (и обычно просто устраняются с целью оптимизации). Различие проявляется в результатах запуска программы. Заметьте, что значения поля І4 для объектов fdl и fd2 уникальны, но значение поля INT_5 не изменяется при создании второго объекта FinalData. Дело в том, что поле INT_5 объявлено как static, поэтому оно инициализируется только один раз во время загрузки класса.

Переменные от v1 до VAL_3 поясняют смысл объявления ссылок с ключевым словом final. Как видно из метода main(), объявление ссылки v2 как final еще не означает, что ее объект неизменен. Однако присоединить ссылку v2 к новому объекту не получится, как раз из-за того, что она была объявлена как final. Именно такой смысл имеет ключевое слово final по отношению к ссылкам. Вы также можете убедиться, что это верно и для массивов, которые являются просто другой разновидностью ссылки. Пожалуй, для ссылок ключевое слово final обладает меньшей практической ценностью, чем для примитивов.

Пустые константы

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

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

Неизменные аргументы

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

Методы f() и g() показывают, что происходит при передаче методу примитивов с пометкой final: их значение можно прочитать, но изменить его не удастся.

Неизменные методы

Неизменные методы используются по двум причинам. Первая причина — «блокировка» метода, чтобы производные классы не могли изменить его содержание. Это делается по соображениям проектирования, когда вам точно надо знать, что поведение метода не изменится при наследовании.

Второй причиной в прошлом считалась эффективность. В более ранних реализациях Java объявление метода с ключевым словом final позволяло компилятору превращать все вызовы такого метода во встроенные (inline). Когда компилятор видит метод, объявленный как final, он может (на свое усмотрение) пропустить стандартный механизм вставки кода для проведения вызова метода (занести аргументы в стек, перейти к телу метода, исполнить находящийся там код, вернуть управление, удалить аргументы из стека и распорядиться возвращенным значением) и вместо этого подставить на место вызова копию реального кода, находящегося в теле метода. Таким образом устраняются издержки обычного вызова метода. Конечно, для больших методов подстановка приведет к «разбуханию» программы, и, скорее всего, никаких преимуществ от использования прямого встраивания не будет.

В последних версиях Java виртуальная машина выявляет подобные ситуации и устраняет лишние передачи управления при оптимизации, поэтому использовать final для методов уже не обязательно — и более того, нежелательно.

Cпецификаторы final и private

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

Это может вызвать недоразумения, так как при попытке переопределения закрытого (private) метода, также неявно являющегося final, все вроде бы работает и компилятор не выдает сообщений об ошибках:

«Переопределение» применимо только к компонентам интерфейса базового класса. Иначе говоря, вы должны иметь возможность выполнить восходящее преобразование объекта к его базовому типу и вызвать тот же самый метод (это утверждение подробнее обсуждается в следующей главе). Если метод объявлен как private, он не является частью интерфейса базового класса; это просто некоторый код, скрытый внутри класса, у которого оказалось то же имя. Если вы создаете в производном классе одноименный метод со спецификатором public, protected или с доступом в пределах пакета, то он никак не связан с закрытым методом базового класса. Так как privat-метод недоступен и фактически невидим для окружающего мира, он не влияет ни на что, кроме внутренней организации кода в классе, где он был описан.

Неизменные классы

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

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

Предостережение

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

Хорошим примером служит стандартная библиотека Java. Класс Vector Java 1.0/1.1 часто использовался на практике и был бы еще полезнее, если бы по соображениям эффективности (в данном случае эфемерной) все его методы не были объявлены как final. Возможно, вам хотелось бы создать на основе Vector производный класс и переопределить некоторые методы, но разработчики почему-то посчитали это излишним.

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

Во-вторых, многие полезные методы класса Vector, такие как addElement() и elementAt(), объявлены с ключевым словом synchronized. Как вы увидите в главе 12, синхронизация сопряжена со значительными издержками во время выполнения, которые, вероятно, сводят к нулю все преимущества от объявления метода как final.

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

Инициализация и загрузка классов

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

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

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

Инициализация с наследованием

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

Запуск класса Beetle в Java начинается с выполнения метода Beetle.main() (статического), поэтому загрузчик пытается найти скомпилированный код класса Beetle (он должен находиться в файле Beetle.class). При этом загрузчик обнаруживает, что у класса имеется базовый класс (о чем говорит ключевое слово extends), который затем и загружается. Это происходит независимо от того, собираетесь вы создавать объект базового класса или нет. (Чтобы убедиться в этом, попробуйте закомментировать создание объекта.)

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

В этой точке все необходимые классы уже загружены, и можно переходить к созданию объекта класса. Сначала всем примитивам данного объекта присваиваются значения по умолчанию, а ссылкам на объекты задается значение null — это делается за один проход посредством обнуления памяти. Затем вызывается конструктор базового класса. В нашем случае вызов происходит автоматически, но вы можете явно указать в программе вызов конструктора базового класса (записав его в первой строке описания конструктора Beetle()) с помощью ключевого слова super. Конструирование базового класса выполняется по тем же правилам и в том же порядке, что и для производного класса. После завершения работы конструктора базового класса инициализируются переменные, в порядке их определения. Наконец, выполняется оставшееся тело конструктора.

Резюме

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

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

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

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *