Основы наследования
Экземпляр класса А, производного от класса В, должен нормально работать в каждом фрагменте программы, которому в качестве параметра передается экземпляр базового типа.
Предположим, у вас имеются функция UseIt(bThing As В) и объект aThing, который является экземпляром производного класса А. Следующий вызов должен нормально работать:
Uselt(aThing)
Если все эти рассуждения выглядят слишком абстрактными, ниже приведен вымышленный (и надеемся, забавный) пример. Предположим, вы размышляете над тем, от какого класса следует объявить производным класс ManagerOfProgrammers – от Manager или от Programmer? Всем известно, что менеджеры носят аккуратные прически, поэтому класс Manager должен содержать метод SetHalrStyle. А теперь закройте глаза и представьте типичного программиста, которого вдруг назначили управлять другими программистами. Захочет ли он менять свой имидж? Можете ли вы уверенно заявить, что вызов вида:
tom.SetHairStyle("sharp razor cut")
Всегда имеет смысл? Конечно, среди программистов иногда встречаются экземпляры, которые заботятся о своей прическе, но обо всех программистах этого никак не скажешь. Мораль: класс ManagerOf Programmers должен быть производным от класса Programmer, а не от Manager.
Примечание
Некоторые языки позволяют объявить класс ManagerOfProgrammers производным как от Manager, так и от Programmer. Теоретически такая возможность выглядит вполне логично и привлекательно, но на практике языки с множественным наследованием (так это называется по-научному) порождают массу проблем. Вместо множественного наследования в VB.NET используется реализация нескольких интерфейсов. Как вы вскоре увидите, этот вариант значительно проще и нагляднее, нежели классическое множественное наследование.
В сущности, при программировании в VB.NET вам никак не удастся скрыться от наследования. Даже если вы привыкли к интерфейсному стилю программирования VB5 и VB6 и считаете, что для ваших задач достаточно интерфейсов вкупе с включением и делегированием, ограничиться одними интерфейсами в VB.NET невозможно. Дело в том, что без явного использования наследования вы не сможете пользоваться .NET Framework. Наследование заложено в основу любого графического приложения .NET, а также многих встроенных классов коллекций – даже работа с объектом FolderBrowser связана с наследованием!
Примечание
Применение наследования при построении графических приложений в рекламной литературе VB.NET иногда именуется визуальным наследованием. Не обращайте внимания – это самое обычное наследование. То, что ваш класс является производным от Windows.Forms.Form, сути дела не меняет.
Более того, сам подход к применению наследования в .NET Framework как нельзя лучше доказывает, что наследование в объектно-ориентированном программировании не должно полностью вытесняться интерфейсами. Подход, примененный в .NET Framework, вполне может применяться и в ваших собственных проектах.
При построении библиотек, используемых другими программистами, хорошо спроектированные классы, прошедшие тщательную отладку и тестирование, могут использоваться другими программистами в качестве базовых.