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