Если методы появились вне интерфейса, то зачем их вызывать извне?.. Над-уровень об этих методах и сущностях ничего не знает и знать ему не положено.
А кто ещё будет вызывать методы, если не надуровень?
Методы может вызывать сам объект, может вызывать система, но если это публичный метод. Имеется ввиду та часть системы, которая обслуживает данный уровень, я обозначу эту часть, как "служебная часть системы".
Да, методы нового класса не входят в интерфейс между уровнями, потому что это методы одного из классов в иерархии классов. А не все классы иерархии имеют одинаковое количество или одинаковые названия для новых методов.
Любой класс иерархии создаётся с целью реализовывать интерфейсы с над-уровнем, вне этого служения ни один класс не имеет смысла.
И ещё: поля класса скрыты от внешнего наблюдателя, поэтому мы можем влиять на них только через имеющиеся методы. Если мы наследуемся от класса, то ко внутреннему состоянию доступа иметь не будем (если разработчик класса об этом не позаботился). Как мы сможем расширить состояние? Мне в голову варианты, полезные на практике, не приходят. Состояние, которое будет добавлено в класс, окажется независимым от состояния исходного класса, а потому, вполне сможет существовать в качестве отдельной сущности (ещё одного класса).
Не все элементы (данные и методы) закрыты для наследования. При разработке класса, надо учитывать возможности его специализации/расширения. Я понимаю, что опять посыплются вопросы о том, что мы заранее не знаем, кто и как будет специализировать/расширять класс... Поэтому сразу отмечу, что развитие иерархии подчинено интерфейсам, интерфейсы определяются архитектурой системы, а архитектура системы, в свою очередь, определяется теми целями и задачами, которые поставлены при создании системы. Это достаточно строгий подход, который вполне поддаётся формализации. (Если я всё же сумею дописать тему "проектирование подсистемы "Сбыт", то там основной акцент делается именно на этом подходе...). Другими словами, рассуждая о развитии понятий атрибуты, отношения, базы данных, нельзя предаваться фантазиям на тему... надо рассуждать строго в рамках заданной темы. Тема любого уровня определяется интерфейсами... как сказано выше.
Вот, у Вас в качестве примера представлена схема реализации атрибутов. Первоначально, как Вы говорите, используется простейшая реализация на массивах. Она не будет использоваться в законченной БД, но очень полезна на этапе реализации. Но когда доходит дело до эффективной реализации атрибутов, то мы оказываемся перед выбором одного из двух вариантов. (В общем случае вариантов может оказаться больше, но меня интересует именно этот частный случай.) Первый вариант - использовать исходный класс в качестве базового для более эффективного. Ко всем сокрытым полям мы доступа не имеем, да и массив нам, в общем-то, не нужен, поэтому мы переопределяем все открытые методы для работы с новой структурой данных. Второй вариант - сделать ещё один класс, имеющий такой же интерфейс, как и первоначальный простой класс. Для того, чтобы языки вроде Java считали интерфейсы этих классов одинаковыми, нужен либо общий предок (обычно, abstract), либо отдельное объявление интерфейса, на которое есть отсылка в исходниках обоих классов. Я отдаю предпочтение второму варианту, а Вы?
Повторю... взаимодействие с любым классом происходит через интерфейсы уровня, никакого прямого обращения к методам или данным объектов нет и быть не может (кроме случаев указанных выше).
Попробуйте рассуждать таким образом... Есть интерфейс, наша задача создать такую иерархию классов, которая позволила бы работать посредством данного интерфейса с определёнными типами данных (для уровня атрибутов), с любыми типами отношений/таблиц (для уровня отношений), с любыми типами баз данных (для уровня баз данных).
