Банк рефератов содержит более 364 тысяч рефератов, курсовых и дипломных работ, шпаргалок и докладов по различным дисциплинам: истории, психологии, экономике, менеджменту, философии, праву, экологии. А также изложения, сочинения по литературе, отчеты по практике, топики по английскому.
Полнотекстовый поиск
Всего работ:
364150
Теги названий
Разделы
Авиация и космонавтика (304)
Административное право (123)
Арбитражный процесс (23)
Архитектура (113)
Астрология (4)
Астрономия (4814)
Банковское дело (5227)
Безопасность жизнедеятельности (2616)
Биографии (3423)
Биология (4214)
Биология и химия (1518)
Биржевое дело (68)
Ботаника и сельское хоз-во (2836)
Бухгалтерский учет и аудит (8269)
Валютные отношения (50)
Ветеринария (50)
Военная кафедра (762)
ГДЗ (2)
География (5275)
Геодезия (30)
Геология (1222)
Геополитика (43)
Государство и право (20403)
Гражданское право и процесс (465)
Делопроизводство (19)
Деньги и кредит (108)
ЕГЭ (173)
Естествознание (96)
Журналистика (899)
ЗНО (54)
Зоология (34)
Издательское дело и полиграфия (476)
Инвестиции (106)
Иностранный язык (62792)
Информатика (3562)
Информатика, программирование (6444)
Исторические личности (2165)
История (21320)
История техники (766)
Кибернетика (64)
Коммуникации и связь (3145)
Компьютерные науки (60)
Косметология (17)
Краеведение и этнография (588)
Краткое содержание произведений (1000)
Криминалистика (106)
Криминология (48)
Криптология (3)
Кулинария (1167)
Культура и искусство (8485)
Культурология (537)
Литература : зарубежная (2044)
Литература и русский язык (11657)
Логика (532)
Логистика (21)
Маркетинг (7985)
Математика (3721)
Медицина, здоровье (10549)
Медицинские науки (88)
Международное публичное право (58)
Международное частное право (36)
Международные отношения (2257)
Менеджмент (12491)
Металлургия (91)
Москвоведение (797)
Музыка (1338)
Муниципальное право (24)
Налоги, налогообложение (214)
Наука и техника (1141)
Начертательная геометрия (3)
Оккультизм и уфология (8)
Остальные рефераты (21697)
Педагогика (7850)
Политология (3801)
Право (682)
Право, юриспруденция (2881)
Предпринимательство (475)
Прикладные науки (1)
Промышленность, производство (7100)
Психология (8694)
психология, педагогика (4121)
Радиоэлектроника (443)
Реклама (952)
Религия и мифология (2967)
Риторика (23)
Сексология (748)
Социология (4876)
Статистика (95)
Страхование (107)
Строительные науки (7)
Строительство (2004)
Схемотехника (15)
Таможенная система (663)
Теория государства и права (240)
Теория организации (39)
Теплотехника (25)
Технология (624)
Товароведение (16)
Транспорт (2652)
Трудовое право (136)
Туризм (90)
Уголовное право и процесс (406)
Управление (95)
Управленческие науки (24)
Физика (3463)
Физкультура и спорт (4482)
Философия (7216)
Финансовые науки (4592)
Финансы (5386)
Фотография (3)
Химия (2244)
Хозяйственное право (23)
Цифровые устройства (29)
Экологическое право (35)
Экология (4517)
Экономика (20645)
Экономико-математическое моделирование (666)
Экономическая география (119)
Экономическая теория (2573)
Этика (889)
Юриспруденция (288)
Языковедение (148)
Языкознание, филология (1140)

Доклад: Интерфейсы как решение проблем множественного наследования

Название: Интерфейсы как решение проблем множественного наследования
Раздел: Рефераты по информатике, программированию
Тип: доклад Добавлен 07:04:26 23 марта 2005 Похожие работы
Просмотров: 368 Комментариев: 2 Оценило: 1 человек Средний балл: 3 Оценка: неизвестно     Скачать

Евгений Каратаев

В этой работе разбирается проблема множественного наследования в языке программирования С++ и возможное ее решение путем применения абстракций интерфейсов.

Множественным наследованием является образование класса путем наследования одновременно нескольких базовых классов. Штука полезная и одновременно с этим проблемная. Разберем пример, в котором появляется множественное наследование, приводящее к проблеме.

Классическим заданием для начинающего программиста является задача написать классы, реализующие иерархию Человек - Студент - Сотрудник. Обычно первым же решением есть образование трех классов в виде:

class Человек { ... };

class Сотрудник : public Человек { ... };

class Студент : public Человек { ... };

В классе Человек декларируются несколько виртуальных и, возможно, абстрактных, функций, которые переопределяются / реализуются в классах-наследниках. Схема на первый взгляд совершенно очевидна и практически ни у кого не вызывает подозрений. Схема реализуется в программе и программа сдается в работу.

Проблема возникает позже, когда оператор приходит и говорит:

- У меня есть человек, который одновременно и сотрудник и студент. Что мне делать?

Реализованная схема, вообще говоря, не предполагает такого варианта - могут быть либо сотрудник, либо студент. Но что-то делать надо. В этот момент приходит на помощь множественное наследование. Программист, не долго думая, создает еще один класс, образованный наследованием и от Сотрудник и от Студент:

class СтудентСотрудник : public Студент, public Сотрудник { ...};

На первый взгляд все в порядке, на второй - полный бардак. Дело в том, что класс Сотрудник, как он был декларирован, содержит в себе полную копию класса Человек. То же самое относится и к классу Студент. Таким образом, класс СтудентСотрудник будет содержать в себе уже 2 копии класса Человек. При этом функции класса Сотрудник будут работать со своим экземпляром класса Человек, а функции класса Студент - со своим. В результате корректного поведения добиться практически очень трудно. В классе СтудентСотрудник придется переопределять все функции базовых классов и вызывать соответствующие функции базовых классов, чтобы модификации обеих копий класса Человек прошли когерентно.

Обнаружив такую ситуацию путем тяжелой отладки, программист приходит к необходимости применения виртуального наследования для исключения дублирования класса Человек. Проблема состоит в том, что виртуальное наследование требует модификации графа наследования базовых классов. Требуемая схема имеет вид:

class Человек { ... };

class Студент : virtual public Человек { ... };

class Сотрудник : virtual public Человек { ... };

class СтудентСотрудник : public Студент, public Сотрудник { ...

};

В этом варианте решена проблема однозначной входимости класса Человек во все классы. Но остается вопрос - не возникнет ли такой же проблемы и дальше с полученным классом СтудентСотрудник? И будет ли возможность произвести модификацию уже работающего кода? В такой ситуации руки могут опуститься - следует либо согласиться с существованием проблемного кода либо действительно идти на полную переработку программы.

Тем не менее элегантное решение существует. Это реализация базовых классов по принципу интерфейсов. Язык С++ не содержит языковой поддержки интерфейсов в явном виде, поэтому будем их эмулировать. Принцип интерфейса состоит в том, что его задачей является не столько реализация класса, сколько его декларация. Нормализуем исходную задачу:

class БытьЧеловеком { ... };

class БытьСтудентом { ... };

class БытьСотрудником { ... };

Исходя из нормализованного множества классов, получим дополнение:

class Человек : public БытьЧеловеком { ... };

class Сотрудник : public БытьЧеловеком, public БытьСотрудником { ... };

class Студент : public БытьЧеловеком, public БытьСтудентом { ...};

class СтудентСотрудник : public БытьЧеловеком, public БытьСтудентом,

public БытьСотрудником { ... };

Формально говоря, такая схема построения классов вполне работоспособна за исключением того, что во многих случаях программисты относятся к интерфейсам слишком уж буквально - оставляют в них только абстрактные функции и реализуют эти функции только в классах-наследниках. В результате полностью выхолащивается идея повторного использования кода. Основанием для нереализации функций в интерфейсных классах обычно служит то, что в классе - интерфейсе нет "ядра" объекта. В нашем случае ядром объекта или классом, реализующим возможность существования объекта, может выступать класс БытьЧеловеком.

Возможным решением проблемы является передача конструктору интерфейсного класса указателя на конструируемый объект с тем, чтобы его запомнить в своем частном поле данных и использовать при реализации функций интерфейса. Примерно по схеме:

class БытьСтудентом

{

БытьЧеловеком& m_БытьЧеловеком;

public:

БытьСтудентом( БытьЧеловеком& init)

: m_БытьЧеловеком( init)

{ ... };

};

class Студент : public БытьЧеловеком, public БытьСтудентом

{

public:

Студент()

: БытьЧеловеком(), БытьСтудентом( *this)

{ ...};

};

В этой схеме, согласно стандарту, также есть проблема - стандарт не гарантирует инициализации конструкторов, указанных в списке инициализации, в том порядке, в котором они перечислены в этом списке. Поэтому мы, передавая *this как аргумент конструктора базового класса, получаем ссылку на негарантированно определенный объект. Выйти из этой ситуации можно, если декларировать конструктор без аргументов и создать дополнительную функцию инициализации, зависящую от *this. Но дублирование ссылок, хранимых в интерфейсных классах, тем не менее, сохраняется и это есть некрасиво.

Для решения этой задачи есть чрезвычайно красивое, на мой взгляд, решение. Решение заключается в том, чтобы не хранить ссылку на ядро объекта, а получать ее динамически. Для этого применяется оператор приведения типа dynamic_cast, применяемый не к классу, а к объекту в процессе работы программы. Пример:

class БытьСтудентом

{

public:

БытьСтудентом(){};

virtual void Func( void);

// пример функции, обращающейся к ядру объекта

{

БытьЧеловеком* ptr = dynamic_cast< БытьЧеловеком* >( this);

if( ptr)

{

// используем ядро

}

};

};

На первый взгляд, приведение типа БытьСтудентом к типу БытьЧеловеком невозможно, поскольку никто их этих классов ни от кого не наследован. Но дело в том, что оператор dynamic_cast определен не для классов, а для объектов. И если при исполнении кода Func реальный объект, для которого эта функция выполняется, имееет класс, унаследованый от БытьЧеловеком, то оператор вернет правильное значение. Согласно стандарту, оператор приведения типа dynamic_cast имеет два вида поведения если приведение невозможно - вернуть нулевое значение либо возбудить исключительную ситуацию. Оба варианта нас полностью устраивают.

Я считаю, что в модели применения интерфейсных классов для решения проблем множественного наследования будет также красиво построить интерфейсные классы с конструкторами, не требующими обращения к ядру объекта. Впрочем, это уже из области философии помехоустойчивого программирования.

Оценить/Добавить комментарий
Имя
Оценка
Комментарии:
Где скачать еще рефератов? Здесь: letsdoit777.blogspot.com
Евгений21:36:28 18 марта 2016
Кто еще хочет зарабатывать от 9000 рублей в день "Чистых Денег"? Узнайте как: business1777.blogspot.com ! Cпециально для студентов!
08:46:55 24 ноября 2015

Работы, похожие на Доклад: Интерфейсы как решение проблем множественного наследования

Назад
Меню
Главная
Рефераты
Благодарности
Опрос
Станете ли вы заказывать работу за деньги, если не найдете ее в Интернете?

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



Результаты(151109)
Комментарии (1843)
Copyright © 2005-2016 BestReferat.ru bestreferat@mail.ru       реклама на сайте

Рейтинг@Mail.ru