Правила об именах

Правила об именах

(В этом разделе мы только формализуем сказанное выше, поэтому при первом чтении книги его можно пропустить.)

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

Конфликты имен: определение и правило

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

Конфликт имен делает класс некорректным за исключением следующих случаев:

1 Оба компонента унаследованы от общего предка, и ни один из них не получен повторным объявлением версии предка.

2 Оба компонента имеют совместимые сигнатуры, и, по крайней мере, один из них наследуется в отложенной форме.

3 Оба компонента имеют совместимые сигнатуры и переопределяются в новом классе.

Ситуация (1) описывает совместное использование при дублируемом наследовании.

Для случая (2) "наследование в отложенной форме" возможно по двум причинам: либо отложенная форма задана родительским классом, либо компонент был эффективным, но порожденный класс отменил его реализацию (undefine).

Ситуации (2) и (3) рассматриваются отдельно, однако, их можно представить как один вариант - вариант соединения (join). Переходя к n компонентам (n >= 2), можно сказать, что ситуации (2) и (3) возникают, когда от разных родителей класс принимает n одноименных компонентов с совместимыми сигнатурами. Конфликт имен не делает класс некорректным, если эти компоненты могут быть соединены, иными словами:

[x]. все n компонентов отложены, так что некому вызвать конфликт определений;

[x]. существует единственный эффективный компонент. Его реализация станет реализацией остальных компонентов;

[x]. два или несколько компонентов эффективны. Класс должен их переопределить. Новая реализация будет использоваться как для переопределяемых компонентов, так и для любых отложенных компонентов, участвующих в конфликте.

И, наконец, точное правило употребления конструкции Precursor. Если в переопределении используется Precursor, то неоднозначность может возникнуть из-за того, что неясно, версию какого родителя следует вызывать. Чтобы решить эту проблему, следует использовать вызов вида Precursor {PARENT} (...), где PARENT - имя желаемого родителя. В остальных случаях указывать имя родителя не обязательно.

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг:

Правила@

Из книги автора

Правила@ Правила @ начинаются с ключевого слова @, непосредственно за которым следует идентификатор (например, @import, @page). Каждый из этих идентификаторов далее рассмотрим подробнее.Все же надо отметить, что браузер с поддержкой CSS будет игнорировать все правила @import, которые


Правила

Из книги автора

Правила Правила используются в таблицах стилей для особых нужд.charsetЗадает текстовую кодировку для внешней таблицы стилей.@charset {Кодировка};Пример:@charset "windows-1251";Может использоваться только во внешних таблицах стилей; должна быть первой строкой в файле. Поддерживается IE


4.4.4. Символические ссылки (еще раз об именах файлов)

Из книги автора

4.4.4. Символические ссылки (еще раз об именах файлов) В разделе об именах файлов уже говорилось о том, что файл в Linux может иметь несколько имен или "жестких ссылок".Жесткая ссылка является просто еще одним именем для исходного файла. Она прописывается в индексном


19.6.5. Правила фильтрации

Из книги автора

19.6.5. Правила фильтрации Задание правил фильтрации IPTables похоже на задание правил в IPChains. Для создания правила используется опция --append (или -А). После этой опции указывается имя цепочки и критерий выбора пакетов в этой цепочке. Затем указывается опция --jump (или -j), значением


§ 165. Три правила про вы

Из книги автора

§ 165. Три правила про вы 7 сентября 2010В русском языке существует местоимение вы, к которому прилагаются довольно простые правила употребления и неупотребления.Вы всегда пишется с маленькойСовершенно невыносима рекламно-подобострастная манера писать Вы с заглавной


1.5. Правила

Из книги автора

1.5. Правила Предположим, мы хотим сформулировать утверждение, что Джону нравятся все люди. Один из способов сделать это заключается в записи для каждого человека, упоминаемого в базе данных, отдельного факта:нравится(джон,альфред). нравится(джон,бертран).


2.1. Синтаксические правила

Из книги автора

2.1. Синтаксические правила Синтаксические правила языка описывают допустимые способы соединения слов. В соответствии с нормами английского языка предложение «I see a zebra» («я вижу зебру») является синтаксически правильным в отличие от предложения «zebra see I а» («зебра видит


2.1.1 Соглашения об именах

Из книги автора

2.1.1 Соглашения об именах Первые библиотеки сокетов писались на языке С. В этом языке идентификаторы чувствительны к регистру символов, т. е., например, SOCKET, Socket и socket — разные идентификаторы. Исторически сложилось, что имена встроенных в C типов данных пишутся в нижнем


Соглашения об именах в VBA

Из книги автора

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


Правила для отступов

Из книги автора

Правила для отступов В каких же строках программного кода следует сделать отступ и какой по величине? Нужно установить отступы одного размера для связанных по смыслу операторов, чтобы связь между такими операторами была зрительно очевидной. Конкретнее говоря,


15.4.3. Правила make

Из книги автора

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


Соглашения об именах

Из книги автора

Соглашения об именах Я пытался выбирать осмысленные имена для объектов, классов, функций, шаблонов и т. п., но семантика некоторых придуманных мной имен может быть для вас неочевидна. Например, я часто использую для параметров имена lhs и rhs. Имеется в виду соответственно


15.4.3. Правила make

Из книги автора

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


Пример 9-17. Изменение расширений в именах файлов:

Из книги автора

Пример 9-17. Изменение расширений в именах файлов: #!/bin/bash# rfe# ---# Изменение расширений в именах файлов.## rfe old_extension new_extension## Пример:# Изменить все расширения *.gif в именах файлов на *.jpg, в текущем каталоге# rfe gif jpgARGS=2E_BADARGS=65if [ $# -ne "$ARGS" ]then echo "Порядок


Правила типизации

Из книги автора

Правила типизации Наша ОО-нотация является статически типизированной. Ее правила типов были введены в предыдущих лекциях и сводятся к трем простым требованиям.[x]. При объявлении каждой сущности или функции должен задаваться ее тип, например, acc: ACCOUNT. Каждая подпрограмма