Albert Makhmutov - Идиомы и стили С++

Хочу еще раз напомнить о принципе, который в этом Шаге формулируется первый раз: если существует определенная, законченная логика взаимодействия объектов или систем - она выносится на отдельный уровень. Поддержка транзакций очевидно является законченной бизнес-логикой, и, следовательно, должна быть вынесена на специальный уровень. Пусть классы реализуют свою функциональность, не заботясь о свопе, многозадачности-поточности, транзакциях, доступе, приоритетах, авторизациях, синхронизации, сборке мусора ( garbage collection) или уплотнении памяти - это не его проблемы. Это - другие уровни, которыми занимаются другие классы, или даже системы. В современном компьютерном мире этот принцип сегодня доминирует, именно на него работают новомодные COM+с MTS, IBM-websphera, JavaBeans, и множество иных. То, что грамотная корпоративная система должна работать в минимум четырех уровнях, уже является прописной истиной: данные, бизнес-логика сервера, бизнес-логика клиента, клиент.

Понимаете теперь, в чем преимущество смарт-указателей? Они позволяют с легкостью создавать новые уровни бизнес-логик без привлечения дополнительных средств и схем, а едиными только средствами языка. Попробуйте сделать что-либо подобное на языке, который не поддерживает указателей и перегрузки операторов (да шаблоны еще)! Вот код.

#include "ampstack.h"

// Абстрактный базовый класс

class CLockable {

friend class CTransaction;

protected:

// текущая транзакция, если есть

CTransaction* m_trans;

public:

CLockable (): m_trans (NULL) {}

// регистрируемся в какой-то транзакции

int regObj (CTransaction* _pt);

// и разрегистрируемся

void unregObj();

virtual ~CLockable() {}

virtual void rollback () =0;

virtual void commit() =0;

};

// Класс транзакции

class CTransaction {

friend class CLockable;

private:

// коллекция зарегистрированных объектов

ampstack‹CLockable› m_locks;

// добавить объект к транзакции

void addLock (CLockable*);

public:

virtual ~CTransaction ();

// закрепить или отменить все изменения во всех

// зарегистрированных объектах.

void commit();

void rollback();

// проверить, зарегистрирован ли объект в этой транзакции

int allready_locked(CLockable*);

};

// зарегистрироваться в транзакции

inline int CLockable::regObj (CTransaction* _pt) {

if (m_trans!= NULL) return 0;

else {

_pt-›addLock(this);

m_trans = _pt;

return 1;

}

}

// разрегистрироваться

inline void CLockable::unregObj() {

m_trans = NULL;

}

// добавление объекта к транзакции.

inline void CTransaction::addLock(CLockable* _lc) {

// а именно, воткнуть указатель на него в стек.

m_locks.push (_lc);

}

// закрепление всех объектов

void CTransaction::commit() {

// создаем итератор

ampIter‹CLockable› it(&(this-›m_locks));

// пробежались по всем, закрепились.

it.goStart();

while (!it.isLast()) it.moveNext()-›commit();

// Всех выкинуть из стека, разрегистрировать.

while (!m_locks.isEmpty()) m_locks.pop()-›unregObj();

}

// отмена всех объектов

void CTransaction::rollback() {

// создали итератор

ampIter‹CLockable› it(&(this-›m_locks));

// пробежались по всем, отменились.

it.goStart();

while (!it.isLast()) it.moveNext()-›rollback();

// Всех выкинуть из коллекции и разрегистрировать

while (!m_locks.isEmpty()) m_locks.pop()-›unregObj();

}

// проверка, зарегистрирован ли объект.

int CTransaction::allready_locked(CLockable* _lc) {

// создали итератор

ampIter‹CLockable› it(&(this-›m_locks));

it.goStart();

while (!it.isLast()) if (it.moveNext() == _lc) return 1;

return 0;

}

Как гарантировать единичность экземпляра некоего класса?

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

1. Создать класс устройства, объявить его экземпляр в специальном файле globals.cpp, и обязать программистов использовать строго его (именно так я делал на заре карьеры; наш шеф под роспись давал нам "Меморандум о писании программ", там много было интересного).