Идиомы и стили С++

// Это все содержится в cpp-файле.

// и первое - определение указываемого объекта

class Cthat {

 friend class CPthat;

private:

protected:

 Cthat;

public:

 // Родной интерфейс.

 void funct1(void);

 void funct2(void);

};

//Реализация членов-функций класса указателя.

CPthat::CPthat :t(new Cthat) {}

CPthat::CPthat (const CPthat& _cp):t(new Cthat(*(_cp.t))) {}

CPthat::~CPthat { delete t; }

CPthat& CPthat::operator=(const CPthat& _cp) {

 if (this != &_cp) {

  delete t;

  t = new Cthat(*(_cp.t));

 }

 return *this;

}

void CPthat::funct1(void) { t-›funct1; }

void CPthat::funct2(void) { t-›funct2; }

// Реализация членов-функций класса объекта

Cthat::Cthat {}

void Cthat::funct1(void) {}

void Cthat::funct2(void) {}

Все, приплыли. От класса указываемых объектов остался только перископ в виде class Cthat;, а более ничего. CPthat действует вместо него. Он сам стал им. Класс CPthat является классом интерфейсного указателя.

Теперь можете идти за пивом. Вы властелин вселенной. Вы можете превратить кого угодно во что угодно. Имея на вооружении идиомы умных, ведущих и интерфейсных указателей, сочетая их в любых комбинациях, Вы можете превратить в урода любой класс на выбор. Или в красавца. Ваше желание - закон, господин. Мне кажется, Вы уже знаете, о чем будет следующий шаг. Но я не могу подобрать нормального термина этому. Слово "интерфейс" заездили до последней степени. Скоро руль и педали назовут интерфейсом автомобиля к шоферу, а вилка, ложка и нож будут универсальным интерфейсом еды. И конечно, Мелкомякг именно это слово применил для следующей идеи. А еще это называют "suite" - комплект, или "facet" - грань. В общем, следующий шаг - о множественных интерфейсных указателях на объект.

Шаг 8 - Еще раз о статистике класса.

Пока праздники не начались и не кончились, пока работает интернет и библиотека, снова займемся любимым делом - статистикой класса. Мы уже говорили о ней, и уяснили, что здесь неплохо работает идиома ведущих указателей. Но на плюсах работает в течение 20 лет сотни тысяч программеров, и было бы неверно предположить, что они за это время не изобрели иных приличных способов реализовать статистику. Так… что же они там навыдумывали?

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

Изящную идиому предложил Коплин в 1995 году, а Мейерс развил ее в 2000. Правда, она предполагает вмешательство в код класса, но это не мешает быть очаровательно красивой. Основана она на том, что мы определяем шаблон класса счетчика и втыкаем его наблюдаемый класс статическим членом или наследованием. Шаблон расширяется ровно один раз для каждого класса, и это гарантирует нам наличие ровно одного экземпляра статистики. Код лучше объяснит.

// Это шаблон класса, ответственного за статистику.

template ‹class T›

class CCounter {

public:

 CCounter { ++m_iCount; }

 CCounter(const CCounter&) { ++m_iCount; }

 ~CCounter { --m_iCount; }

 static int GetCount { return m_iCount; }

private:

 static int m_iCount;

};

// Парашютики, парашютики берем не забываем!

// Инициализируем статическую мембер-переменную.

template ‹class T› int CCounter‹T›::m_iCount = 0;

// Использование статистики.

class CClass {

public:

 static int GetCount { return CCounter‹CClass>::GetCount; };

private:

 CCounter‹CClass› cInstance;

};