Главная » Java » Наследование классов: как и когда Java

0

 

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

Приведем пример. Рассмотрим класс Роint, представляющий посредством пары значений (х, у) точку в двухмерном пространстве. Легко построить класс Piхеl, расширяющий класс Роint с целью представления окрашенной точки на экране компьютера. Piхеl есть Роint – все, что справедливо в отношении Роint, справедливо и для Piхеl. В классе Piхеl могут быть предусмотрены механизм описания цвета точки и ссылка на объект, представляющий экран, на котором размещаются точки-пиксели. Как элемент двух мерного пространства (плоскости экрана) с дополнительными атрибутами (цветовым признаком и границами прямоугольной области), Piхеl подчеркнем еще раз – есть Роint.

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

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

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

один из наиболее тривиальных и часто применяемых подходов состоит в создании базового класса – назовем его Еmрlоуее (служащий), - который содержит информацию, общую для всех сотрудников, и построении на его основе производных классов для каждой категории служащих (скажем, Manager, Enineer, FileClerk и т.п,), Подобный дизайн в реальных ситуациях может оказаться ущербным, если один и тот же сотрудник выполняет в компании одновременно несколько функций. Например, нередки случаи, когда инженер является руководителем группы, менеджер высшего эшелона занимается конкретными техническими проблемами или лаборант работает в университете и в то же время учится в нем,

Более гибкий способ решения задачи состоит в создании базового класса Rolе (должность) и нескольких про из водных классов (таких как Manager), каждый из которых описывает особенности конкретной должности. Далее надлежит исправить объявление класса Employee, предусмотрев в нем возможность хранения набора ссылок на объекты Rolе. Теперь конкретному сотруднику – он описывается объектом класса Employee – легко поставить в соответствие требуемый набор должностей (ссылок на объекты Role). Таким образом, мы перешли от модели "менеджер есть служащий" к модели "менеджер есть должность", и нынче наш служащий способен обладать должностью менеджера, а также любыми другими возможными должностями.

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

 

Источник: Арнолд, Кен, Гослинг, Джеймс, Холмс, Дэвид. Язык программирования Java. 3-е изд .. : Пер. с англ. – М. : Издательский дом «Вильяме», 2001. – 624 с. : ил. – Парал. тит. англ.

По теме:

  • Комментарии