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

 

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

Во-первых, требуется четко документировать последствия переопределения каждого метода в этом классе. Иными словами, для класса должно быть докумен­тировано, какие из переопределяемых методов он использует сам (self-use): для каждого открытого или защищенного метода, каждого конструктора в документации должно быть указано, какие переопределяемые методы он вызывает, в какой после­довательности, а также каким образом результаты их вызова влияют на дальнейшую обработку. (Под переопределяемостью (overridable) метода здесь подразумевается То, что он является неокончательным, а также что он либо открытый, либо защищен­ный.) В общем, в документации должны быть отражены все условия, при которых класс может вызвать переопределяемый метод. Например, вызов может поступать из фонового потока или от статического метода-инициализатора.

По соглашению, метод, который сам вызывает пере определяемые методы, должен содержать описание этих обращений в конце своего dос-комментария. Такое Описание начинается с фразы "This implementation". Эту фразу не следует использовать лишь для того, чтобы показать, что поведение метода может меняться от версии к версии. Она подразумевает, что следующее описание будет касаться внутренней работы данного метода. Приведем пример, взятый из спецификации класса java.util.AbstractCollection:

publlic boolean remove(Object о)

 

75

 

 

Удаляет из данной коллекции один экземпляр указанного элемента, если таковой имеется (необязательная операция). Или более формально: удаляет элемент е, такой, что (о == null ? е == null : о.equals(e)), при условии, что в коллекции содержится один или несколько таких элементов. Возвращает значение true, если в коллекции присутствовал указанный элемент (или, что то жe самое, если в результате этого вызова произошло изменение коллекции).

В данной реализации организуется цикл по коллекции с поиском заданного элемента. Если элемент найден, он удаляется из коллекции с помощью метода remove, взятого у итератора. Метод iterato r коллекции возвращает объект итератора. Заметим, что если

у итератора не реализован метод гетоуе, то данная реализация инициирует исключительную ситуацию Unsuppo rtedOpe rationException.

 

Приведенное описание не оставляет сомнений в том, что переопределение метода iterator повлияет на работу метода гетоуе. Более того, в ней точно указано, каким образом работа экземпляра Iterator, возвращаемого методом iterator, будет влиять ii работу метода гетоуе. Сравните это с ситуацией, рассмотренной в статье 14, когда программист, создающий подкласс для HashSet, просто не мог знать, повлияет  переопределение метода add на работу метода addAll.

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

Проектирование наследования не исчерпывается описанием того, как класс исполь­зует сам себя, для того чтобы программисты могли писать полезные подклассы, не прилагая чрезмерных усилий, от класса может потребоваться создание механизма для диагностирования своей собственной внутренней деятельности в виде пра­вильно выбранных защищенных методов или, в редких случаях, защищенных полей. Например, рассмотрим метод removeRange из класса j ava. util. Abst ractList:

protected void removeRange(int fromlndex, int tolndex)

 

Удаляет из указанного списка все элементы, чей индекс попадает в интервал от fromlndex (включительно) до tolndex (исключая). Все последующие элементы сдвигаются влево (уменьшается их индекс). Данный вызов укорачивает список ArrayList на (tolndex - fromlndex) элементов. (Если tolndex == fromlndex, процедура ни на что не влияет.)

 

Этот метод используется процедурой clea r как в самом списке, так и в его подсписках (subList - подмножество из нескольких идущих подряд элементов.- Прuм. пер.). При переопределении этого метода, дающем доступ к деталям реализации списка, можно значительно повысить производительность операции очистки как для списка, так и для его подсписков.

 

76

 

В данной реализации итератор списка ставится перед fromlndex, а затем в цикле делается вызов Listrterator. next, за которым следует Listlterator. remove. И так до тех пор, пока полностью не будет удален указанный диапазон. Примечание: если время выполнения операции Listlterator. гетоуе зависит от числа элементов в списке линейным образом, то в данной реализации зависимость является квадратичной.

Параметры:

Fromlndex              индекс первого удаляемого элемента индекс

 

 tolndex                   последнего удаляемого элемента

 

Описанный метод не представляет интереса для конечных пользователей реализации List. Он служит только для того, чтобы облегчить реализацию в подклассе быстрого метода очистки подсписков. Если бы метод removeRange отсутствовал, в подклассе пришлось бы довольствоваться квадратичной зависимостью для метода clear, вызы­ваемого для подсписка, либо полностью переписывать весь механизм subList - зада­ча не из легких!

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

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

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

 

77

 

 

Есть лишь несколько ограничений, которым обязан соответствовать класс, чтобы его наследование стало возможным. Конструкторы класса не должны вызывать переопределяемые методы, непосредственно или опосредованно. Нарушение этого правила может привести к аварийному завершению программы. Конструктор супер­класса выполняется прежде конструктора подкласса, а потому переопределяющий метод в подклассе будет вызываться перед запуском конструктора этого подкласса. И если переопределенный метод зависит от инициализации, которую осуществляет конструктор подкласса, то этот метод будет работать совсем не так, как ожидалось. для пояснения приведем пример класса, нарушающеГ9 это правило:

public class Supeг {

// Ошибка: конструктор вызывает переопределяемый метод

public Supeг() {

me();}

public void m() {

}

}

Представим подкласс, в котором переопределяется метод т, неправомерно вызы­ваемый единственным конструктором класса Supeг:

final class Sub extends Supeг {

pгivate final Date date;

// Пустое поле final заполняется конструктором

Sub() {

date = new Date();

}

// Переопределяет метод Supeг.m, используемый конструктором

Super() publiC void m() {

System.out.println(date); }

public static void main(Stгing[] aгgs) {

 Sub s = new Sub();

s.m();

}

}

Предполагается, что эта про грамма напечатает текущую дату дважды, однако в первый раз она выводит null, поскольку метод т вызывается конструктором Supeг() прежде, чем конструктор Sub() получает возможность инициализировать поле даты. Отметим, что данная программа видит поле final в двух разных состояниях.

 

 

78

Реализация интерфейсов Cloneable и Se гializable при проектировании наследо­вания создает особые трудности. Вообще говоря, реализовывать какой-либо из этих интерфейсов в классах, предназначенных для наследования, не очень хорошо уже потому, что они создают большие сложности для программистов, расширяющих этот класс. Есть, однако, специальныe приемы, которые можно использовать с тем, чтобы обеспечить передачу реализации этих интерфейсов в подкласс, а не заставлять его реализовывать их заново. Эти приемы описаны в статьях 10 и 54.

Если вы решите реа-лизовать интерфейс Cloneable или Seгializable в классе, предназначенном для наследования, то учтите, что, поскольку методы clone и гead­Obj edt в значительной степени работают как конструкторы, к ним применимо то же самое ограничение: ни методу clone, ни методу readObject не разрешается вызы. вать переопределяемый метод, непосредственно или опосредованно. В случае с методом readObj ect переопределенный метод будет выполняться перед десериали­зацией состояния подкласса. Что же касается метода clone, то переопределенный метод будет выполняться прежде, чем метод сlопе в подклассе получит возможность установить состояние клона. В обоих случаях, по-видимому, последует сбой програм­мы. При работе с методом clone такой сбой может нанести ущерб и клонируемому объекту,  и клону.

И, наконец, если вы решили реализовать интерфейс Serializable в классе, предназначенном для наследования, а у этого класса есть метод readResolve или wri teReplace, то вы должны делать этот метод не закрытым, а защищенным. Если эти методы будут закрытыми, то подклассы будут молча игнорировать их. Это еще один случай, когда для обеспечения наследования детали реализации класса становятся частью его АРI.

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

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

Наилучшим решением этой проблемы является запрет на создание под·классов для тех классов, которые не были специально разработаны и не имеют требуемого описания для безопасного выполнения данной операции. Запретить создание подклассов можно двумя способами. Более простой заключается в объявле­нии класса как окончательного (final). Другой подход состоит в том, чтобы сделать все Конструкторы класса закрытыми или доступными лишь в пределах пакета, а вместо них создать открытые статические методы генерации. Такая альтернатива, дающая возможность гибко использовать класс внутри подкласса, обсуждалась в статье 13. Приемлем любой из указанных подходов.

 

 

79

 

 

Возможно, этот совет несколько сомнителен, поскольку так много программистов выросло с привычкой создавать для обычного неабстрактного класса подклассы лишь для того, чтобы добавить новые возможности, например средства контроля, оповеще­ния и синхронизации, либо наоборот, чтобы ограничить его функциональные воз­можности. Если класс реализует некий интерфейс, в котором отражена его сущность, например Set, List или Мар, то у вас не должно быть сомнений по поводу запрета под­классов. Шаблон класса-оболочки (wrapper class), описанный в статье 14, создает превосходную альтернативу наследованию, используемому всего лишь для изменения функциональности.

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

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

 

 

⇐ Предыдущая11121314151617181920Следующая ⇒

Поделиться: