Общие черты стратегий реализации Ival_box.

Рубрика: C++, Дата: 1 April, 2013, Автор:
Tags:

Определите в общих чертах конкретные стратегии реализации примера Ival_box, из 12 параграфа, основываясь на идее о том, что каждый видимый приложению класс является интерфейсом, содержащим единственный указатель на реализацию. Таким образом каждый интерфейсный класс будет выполнять роль дескриптора для класса реализации, и будут существовать иерархии интерфейсов и иерархии реализаций. Напишите фрагменты кода, иллюстрирующие возможные проблемы с приведением типов. Рассмотрите возможности упрощения использования, программирования, повторного применения интерфейсов и реализации при добавлении новых концепции иерархий, упрощение модификации интерфейсов и реализации, а также необходимость перекомпиляции после внесения изменений в реализацию.

Что ж приступим. Щас я чуток почитаю 12 параграф для начала.

И так поехали будем разбирать по предложению.

Первое. “Определите в общих чертах конкретные стратегии реализации примера Ival_box, из 12 параграфа, основываясь на идее о том, что каждый видимый приложению класс является интерфейсом, содержащим единственный указатель на реализацию.” Да ну что там стратегии таки: первая это реализовать реализацию Ival_box в виде базового класса, от которого уже пойдут производные классы. Это первая стратегия. Затем вторая стратегия реализовать Ival_box в виде также базового класса но класс bbWindow уже не делать базовым для Ival_box, а использовать множественное наследование для производных классов от Ival_box. Ну и третья стратегия это реализовать Ival_box и в виде абстрактного класса и просто переопределить для класса bbWindow если есть потомки например для bbSlider, создать и потомка для Ival_box и просто сделать двойное наследование, как бы на прямую определить готовый класс.

Это что в параграфе описано, а нам нужно новую схему составить, типо каждый видимый класс содержит указатель на реализацию хз. Ничо я тут не понял.

Второе. “Таким образом каждый интерфейсный класс будет выполнять роль дескриптора для класса реализации, и будут существовать иерархии интерфейсов и иерархии реализаций.” Ну да наверно будут это ведь утверждение, а не вопрос.

Третье. “Напишите фрагменты кода, иллюстрирующие возможные проблемы с приведением типов.”  Увы этот код я не напишу.

Четвертое. “Рассмотрите возможности упрощения использования, программирования, повторного применения интерфейсов и реализации при добавлении новых концепции иерархий, упрощение модификации интерфейсов и реализации, а также необходимость перекомпиляции после внесения изменений в реализацию.”  Ну фиг его знает. Где то читал, что перекомпиляция обязательная если изменяется базовый класс. хз. Пропустим эту задачку.

Вообщем это способ будет без использования наследования, тоесть класс который должен быть базовый при этом способе просто инициализируется внутри класса который должен быть производным, и вызывается его конструктор. Как бы таже реализация, токо в профиль.

rss