Во избежание неясностей поясню о чём идёт речь. Предположим, что мы рассматриваем два уровня системы. Взаимодействие между этими уровнями происходит через интерфейсы. Незыблемость интерфейсов - залог работоспособности системы. Но вот мы начинает реализацию этих интерфейсов на нижнем (из рассматриваемых) уровней. На основе заданных интерфейсов проектируем иерархию классов, часть методов которых являются публичными, соответствующими заявленным интерфейсам.
Ну а как тогда использовать преимущества (или дополнения) у наследников, если интерфейс между уровнями у нас задан жёстко? Или другими словами - как вызвать методы, которые появились у наследников?
Если методы появились вне интерфейса, то зачем их вызывать извне?.. Над-уровень об этих методах и сущностях ничего не знает и знать ему не положено.
Если же речь идёт о развитии интерфейса, то под-уровень, реализует это развитие у себя, а над-уровень, обращается к расширенному интерфейсу.
Поясню на примере проекта СУБД, о котором говорилось. Первоначально атрибуты были организованы примитивно просто - массивы однородных данных. Для уровня отношений (таблиц) совершенно безразлично, как устроены атрибуты отношения (таблицы), оно обращается к атрибутам однозначно (найти, выбрать, добавить, заменить и т.д.). Быстрая (хоть и примитивная) реализация атрибутов (хотя бы одного типа!), позволяет разрабатывать и отлаживать логику уровня отношений совершенно независимо от атрибутов. Аналогично логика базы данных разрабатывается совершенно независимо от уровня отношений (таблиц). Всё это хорошо, но... для реальной СУБД неприменимо. И тогда начинается внутреннее развитие уровней, где используются более изощрённые механизмы (и соответствующие методы). Но влияет ли такое развитие на логику смежных уровней? Нет, не влияет. Теперь мы реализовали то, что нужно реальной СУБД, она эффективно хранит информацию, быстро её ищет и извлекает, умеет добавлять, изменять и удалять информацию. Здорово! Пришло время подумать о сервисных функциях... И тогда мы расширяем интерфейсы уровней, добавляя в них новые элементы, и точно также можем сначала реализовать простейшие варианты, а потом их улучшать...
Означает ли это, что простейшие варианты повисают в системе "мёртвым грузом"? Нет, не означает. Они могут использоваться самой системой. Те же атрибуты, которые представлялись простым массивом однородных данных вполне пригодились для... реализации отношений. Ведь отношение - это массив атрибутов, а атрибуты (независимо от их типа) внутри отношения представляются просто, как "атрибут". Аналогично и с другими простыми реализациями... они все оказались востребованными.