Это можно сделать и без наследования.
Да, можно... Вопрос:
ЗАЧЕМ?
[/quote]
Потому что это будет явно и прозрачно, с полной ответственностью программиста за то, что он делает.
Он объявляет свой MegaButton как расширение AbstractButton - он должен определить ВСЕ методы AbstractButton, подумать над ними - может быть, значительная часть из них и будет тупо состоять из вызова this.base.Method() (что тут является аналогом супервызова) - но он будет явно принимать это решение.
А не тупо "перекрыть-переклепать" то, что ему там не нравится, в надежде, что всё остальное будет "дёргаться" автоматически.
Конечно, не надо создавать такие классы, как в VCL - с десятками методов. В большинстве случаев, если у объекта больше десятка методов, его уже пора "резать" на несколько.
Проект СУБД я помню, внимательно смотрел, погляжу ещё раз и попробую переформулировать без наследования 
Хм?.. А перевести в мирное русло... не пробовали?
[/quote]
Посмотрел. Там наследование, например, применяется для реализации разных типов атрибутов.
Атрибут (Фиксированный размер (числа, временные), Произвольный размер (строки, blob)).
Конечно, наследование тут полезно, но не обязательно реализации.
Можем сделать для них дерево абстрактных классов без реализаций.
Затем уже делаем реализацию каждого "терминального" класса из дерева. Реализации полностью независимы друг от друга, ничего не знают друг про друга. Потом замечаем, что реализация, допустим, блоба, в чём-то начинает повторять код реализации строк. Мы сразу же выносим этот код в некоторую базовую библиотеку, состоящую из функций или наших служебных классов. Т.е. код, который бы хотелось наследовать (засунуть в класс "Произвольный размер", чтобы потом от притащился автоматом при наследовании и в строки, и в блобы) мы просто выносим отдельно в свои служебные модули. Возникнут какие-то внутрение служебные классы, в которых будет зафиксирована вот эта общность реализаций разных атрибутов.
