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

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

Рис. 14.11.  Механизмы наследования и их роль

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

Взгляд на класс как на модуль

С этой точки зрения наследование особенно эффективно в качестве метода повторного использования.

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

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

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

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

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

[x]. Открытой, так как нет никакой гарантии, что с самого начала в модуль были включены все службы, потенциально необходимые некоторому клиенту.

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