
- •Тема 5.3. Средства объектно-ориентированного программирования в vb
- •5.3.1. Две роли классов в ооп и типы данных в vb
- •5.3.2. Средства создания классов в vb
- •5.3.2.1. Средства создания пользовательских классов
- •5.3.2.2. Пошаговое руководство для создания приложения с классами
- •Определение класса
- •Создание кнопки для тестирования класса
- •Запуск приложения
- •5.3.3. Взаимодействие, взаимное различие и сходство форм, модулей и классов
- •5.3.4. Создание объектной модели и приложений с использованием классов
- •5.3.5. Иерархия классов и наследование
- •Наследование и тождественность
- •Базовые классы и повторное использование кода
- •Взаимозаменяемые производные классы
- •Неполные иерархии классов
- •Глобальные изменения производных классов через базовый класс
- •Изменение структуры базовых классов после развертывания
- •Проблема уязвимости базовых классов
- •Сведение к минимуму проблем уязвимости базовых классов
- •5.3.6. Задачи для самостоятельного решения по теме «Средства объектно-ориентированного программирования в Visual Basic»
- •Практикум
- •5.3.7. Тестовые задания по теме «Средства объектно-ориентированного программирования в vb»
- •Тема 5.3. Средства объектно-ориентированного программирования в Visual Basic Страница 85
Неполные иерархии классов
Наследование лучше всего использовать для относительно неполных иерархий классов. Слишком глубокие и сложные иерархии классов могут оказаться трудными для разработки. Решение использовать иерархию классов подразумевает выбор между преимуществами иерархии классов и ее сложностью. Обычно рекомендуется использовать не более шести уровней иерархии. Однако максимальная глубина каждой отдельной иерархии классов зависит от ряда факторов, включающих степень сложности на каждом уровне.
Глобальные изменения производных классов через базовый класс
Одной из самых мощных возможностей наследования является способность вносить в базовый класс изменения, которые передаются производным классам. Если ее использовать грамотно, то можно обновить реализацию лишь одного метода, а десятки или даже сотни производных классов смогут использовать новый код. Однако это может быть небезопасно, так как подобные изменения могут вызвать проблемы с унаследованными классами, разработанными другими пользователями. Необходимо удостовериться, что новый базовый класс совместим с классами, использующими первоисточник. С особой осторожностью следует относиться к изменению имени или типа членов базового класса.
Например, пользователь разрабатывает базовый класс с полем типа Integer, в котором хранятся данные о почтовом индексе, а другие разработчики создают производные классы, которые используют унаследованное поле почтового индекса. Предположим, что поле почтового индекса пользователя содержит пять цифр, а на почте к индексу добавляют дефис и еще четыре цифры. В худшем случае придется изменить поле в базовом классе, расширив строку до 10 знаков, но другим разработчикам тогда придется снова компилировать производные классы, чтобы использовать новый размер и тип данных.
Наиболее безопасным способом изменения базового класса является простое добавление новых членов. Например, можно добавить новое поле для хранения четырех дополнительных цифр почтового индекса. Таким образом, клиентские приложения можно обновить для использования нового поля без изменения существующих приложений. Возможность расширять базовые классы в иерархии наследования является значительным преимуществом, которым не обладают интерфейсы.
Изменение структуры базовых классов после развертывания
В идеале, иерархии класса никогда не меняются после развертывания, поскольку даже незначительные изменения могут привести к непредвиденным последствиям. В реальности таких изменений иногда не избежать: требования к продукту могут измениться, и в спецификациях разработки иногда пропущены ключевые элементы. Одна из категорий проблем наследования известна как проблема уязвимости базовых классов.
Проблема уязвимости базовых классов
Главным недостатком использования иерархий наследования является проблема уязвимости базовых классов. Изменения в базовых классах часто требуют изменения, повторной компиляции и перераспределения базового класса и всего кода в производных классах. Если несколько разработчиков создают базовый класс и производные классы, эта проблема может усложниться из-за того, что каждая из сторон может запретить доступ к своему исходному коду. В худшем случае клиент может неумышленно использовать скомпилированную двоичную форму обновленного базового класса с исходной и несовместимой двоичной версией производных классов.
Изменения базового класса, которые могут оказаться разрушительными для производных классов, включают в себя переопределение или изменение типа данных членов базового класса.