Базовый интерфейс компонент
Query interface – запрос интерфейса по GUID. Если поддерживается, то получить ссылку на реализацию:
Сервер
То, что много клиентов может использовать иной сервер (компонента- сервер), порождает проблему сборки мусора.
Решение этой проблемы:
-Release (освобождение)
-AddRef (добавление ссылок)
Вызов сборщика мусора, если счётчик =0, если не является равным 0 , то уменьшает счётчик ссылок на 1.
Проблема множественности иерархий
Мышление в терминах иерархий (уточнение строения, уточнение поведения) естественно для человеческого мышления.
В несистематизированных и хорошо систематизированных областях построение иерархии - очень трудное дело. Ведь чтобы описать полнее ситуацию требуется много иерархий.
Проектирование классов занимает до 80% всего времени разработки.
На деле для полной идентификации объектов необходимо, чтобы любые два объекта попадали в различные классы при какой-либо классификации в какой-нибудь иерархии.
Проблемы:
Коллизия имён
Коллизия реализации
Общий подход к решению:
- одну иерархию рассматривать как основную: иерархия классов, наследование реализации
- другие иерархии связывать с иерархиями интерфейсов: наследование имён
«Симметричное» решение – агрегаты (декартовы произведения классов)
Агрегирование- возможность использования в качестве полей классов (т.е. ссылки на другие классы).
Помимо общей для ООП проблемы обязательности наследования всех полей наследуемого метода, множественное наследование и агрегирование порождают более точную семантическую проблему отсутствия приоритетов наследования.
Эта проблема решается разделением существительных и прилагательных:
- выделить нечто главное как существительное
- рассмотреть иные иерархии, а затем выразить нечто вторичное в виде прилагательных (это чётко видно в именах)
Множественное наследование
Пример:
cEva
C
lass
сChildren
{
cDad Dad;
cMum Mum;
}
cSun cDad cMum
Таким образом, в классе полями могут быть классы.
«Асимметричное» решение - именованные интерфейсы
Проблема:
Существует два фрагмента кода, единственным различием которых является то, что методы имеют разные параметры.
К счастью, решить подобные проблемы позволяют интерфейсы (interfaces). Они определяют, какие методы должны присутствовать в классе.
Интерфейс — такой же абстрактный класс, в котором нет полей и не определены тела у методов, т.к. интерфейс определяет список методов класса с определёнными именами, типами и параметрами.
Таким образом, интерфейсы не хранят данные, поэтому к ним нельзя добавлять поля. Дело в том, что интерфейс определяет список методов класса с определёнными именами, типами, параметрами.
Класс реализует интерфейс, если в нём реализуются все его методы.
Основная идея- возможность ссылки на интерфейс (на несколько интерфейсов).
Интерфейсы не предназначены для борьбы с дублирующимся кодом. Они просто позволяют использовать один и тот же класс в разных ситуациях.
Замечание: один класс может реализовывать несколько интерфейсов.
Абстрактный класс — класс, в котором нет полей и который имеет хотя бы один абстрактный метод (abstract).
Абстрактный класс по семантике (не по синтаксису и не по происхождению, отличному от чистого ООП) можно сопоставить именованному интерфейсу.
Таким образом, функционально любой интерфейс является абстрактным классом, но абстрактный класс не является интерфейсом.