Делегирование

В первоначальном проекте множественного наследования, который был представлен на Европейской конференции группы пользователей UNIX, состоявшейся в Хельсинки в мае 1987 г. [Stroustrup, 1987], фигурировало понятие делегирования [Agha, 1986].

Пользователю разрешалось задать указатель на некоторый класс вместе с именами базовых классов в объявлении класса. Описанный таким образом объект использовался точно так же, как если бы это был объект, представляющий базовый класс. Например:

class B { int b; void f(); };
class C : *p { B* p; int c; };

Нотация : *p означает, что объект, на который указывает p, будет использоваться так, будто он представляет базовый класс для C.

void f(C* q)
{
   a->f(); // означает q->p->f()
}

<...>

Концепция выглядела многообещающей для представления структур, требующих большей гибкости, чем может дать обычное наследование. В частности, присваивание делегирующему указателю могло бы использоваться для изменения конфигурации объекта во время исполнения. Реализация была бы тривиальной, затраты — минимальными. Поэтому данную идею испытали несколько пользователей. Много времени и сил здесь пололжил Билл Хопкинс (Bill Hopkins). К сожалению, все пользователи, применившие механизм делегирования, пострадали от серьезных ошибок и путаницы. Из-за этого возможность была исключена как из проекта, так и из Cfront версии 2.0.

Причины ошибок:

функции в делегирующем классе не замещают функции в классе, которому операция делегируется;

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

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

Сегодня мне кажется, что указанные проблемы имеют фундаментальный характер. Для решения первой потребовалось бы изменять таблицу виртуальных функций объекта, которому делегируется управление, если он связан с делегирующим объектом. Это плохо согласуется с языком в целом и с большим трудом поддается разумному определению. Кроме того, обнаружились примеры, когда мы хотели, чтобы два разных объекта делегировали управление одному и тому же "разделяемому" объекту. Нашлись и такие задачи, в которых нужно было делегировать управление через B* объекту производного класса D.

ПК>// Класс, которому будем делегировать.
ПК>class A
ПК>{
ПК>   public void a() { }
ПК>   public void b() { }
ПК>};

ПК>// Класс, который делегирует
ПК>class B
ПК>{
ПК>   // Явное делегирование
ПК>   public void a() { a_.a(); }

ПК>   // Какая-то "магия" c TransparentProxy, чтобы остальные методы тоже делегировались.
ПК>   // . . .

ПК>   private A a_;
ПК>};
ПК>

MyRealProxy rp = new MyRealProxy(classAInstance);
ClassA classAWrapper = (ClassA)rp.GetTransparentProxy();

public override IMessage Invoke(IMessage msg)
{
    IMethodCallMessage mcm = (IMethodCallMessage)msg;
    IMethodReturnMessage rm = RemotingServices.ExecuteMessage(m_Instance, mcm);
    // Some stuff
    return rm;
}

bool
byte
char
DateTime
decimal
double
short
int
long
sbyte
single
string
Type
ushort
uint
ulong

public void ForEachMember<T>(Action<T> action)
        where T : RTypeMember
public RMemberMethod[] FindMethods(string name)
public T[] FindMember<T>(RModifier modifiers)
        where T : RTypeMember
public T[] FindMember<T>(Predicate<T> predicate)
        where T : RTypeMember
public int RemoveAll<T>()
    where T : RTypeMember
public int RemoveAll<T>(RModifier modifiers)
    where T : RTypeMember
public int RemoveAll<T>(Predicate<T> predicate)
    where T : RTypeMember

ПК> Так что, если уж поминать STL, то в этом отношении в Java сделано скорее ближе к тому, как в STL, чем к тому, как в .Net

> И вообще, если все методы (пусть и статические) помещать в класс к которому они относятся, то любой дурак нажав точку в IDE получит их список.

Ты говоришь о другой ситуации, а именно о помещении функции sort в класс Array. Дело спорное, т.к. нарушает Open-Closed Principle, но вопрос совсем отдельный.

>> Хотя как в Яве могут быть методы не экземплярные и не статические одновременно?

ПК>Елки-палки, лес густой Я именно об этом вместе с INTP_mihoshi и говорил,

То же, что и в Яве, то, что в нем объектом приходится делать даже то, что объектом не является.

И вообще, если все методы (пусть и статические) помещать в класс к которому они относятся, то любой дурак нажав точку в IDE получит их список.

Ты говоришь о другой ситуации, а именно о помещении функции sort в класс Array.