С этой точки зрения наследование особенно эффективно в качестве метода повторного использования.
Модуль это множество служб, предлагаемых внешнему миру. Без наследования каждому новому модулю пришлось бы самому определять все предоставляемые им службы. Конечно, реализации этих служб могут основываться на службах, предоставляемых другими модулями: это и есть цель отношения "быть клиентом". Но единственным способом определить новый модуль является добавление новых служб к ранее определенным модулям.
Наследование предоставляет эту возможность. Если B является наследником A, то все службы (компоненты) A автоматически доступны в B, и их не нужно в нем явно определять. В соответствии со своими целями B может добавить новые компоненты. Дополнительная гибкость обеспечивается переопределением, позволяющим B по-разному использовать реализации, предлагаемые A: некоторые из них не меняются, а другие переделываются в более подходящие для данного класса версии.
Это приводит к такому стилю разработки ПО, при котором вместо попытки решать каждую новую задачу с нуля поощряется ее решение, основанное на предыдущих достижениях и на расширении их результатов. Его смысл состоит в экономии - зачем повторять то, что уже однажды было сделано? - и в скромности, в духе известного замечания Ньютона, что он смог достичь таких высот только потому, что стоял на плечах гигантов.
Полное преимущество этого подхода лучше всего понимается в терминах принципа Открыт-Закрыт, введенного в одной из предыдущих лекций. (Стоило бы перечитать этот раздел в свете только что введенных понятий.) Этот принцип утверждает, что хорошая структура модуля должна быть и закрытой, и открытой.
Если бы довести эту идею до предела, то каждый класс просто добавлял бы один компонент к его родителям! Конечно, это не рекомендуется. Решение завершить класс не следует принимать легковесно, оно должно основываться на осознанном заключении о том, что класс в его нынешнем состоянии уже обеспечивает логически последовательный набор служб - стройную абстракцию данных - для потенциальных клиентов. Следует помнить, что принцип Открыт-Закрыт не отменяет последующей переделки неадекватных служб. Если плохой результат явился следствием неверной спецификации компонента, то мы не сможем модифицировать класс так, чтобы это не отразилось на его клиентах. Однако, благодаря переопределению, принцип Открыт-Закрыт все еще применим, если вводимое изменение согласовано с объявленной спецификацией. |
Эта диаграмма наследования представляет только набросок, хотя на ней показаны типичные для этих структур связи по наследованию. Систематическую классификацию таблиц и других контейнеров, основанную на наследовании, см. в [M 1994a]. |