Tortuga

Archived

Table of Contents

Concept
Common *Manager Methods
Theoretical Solution

Concept

Usually, whenever you have multiple classes with similar code, you would inherit one from the other, or both from a common ancestor. Currently, AccountManager and CharacterManager (and hopefully RoomManager) share all of their method names, so ideally I'd write an interface class. However, since each requires a different number of parameters to some of these methods, I can't do that. Instead, I'll list the methods here.

Common *Manager Methods

An ellipsis (...) indicates a list of variable parameter types, and T is the type handled by the manager class.

//basic management methods
int Create(...)
int Load(...)
int Save(int uid)
void Unload(int uid)
void Delete(int uid)

void UnloadAll()
UnloadIf(std::function<bool(std::pair<int, T>)> fn)

//accessors
T* Get(int uid)
int GetLoadedCount() //number of elements in memory
int GetTotalCount() //number of elements in database
std::map<int, T>* GetContainer() //OO Breaker, I couldn't fix this :(

//database hooks
sqlite3* SetDatabase(sqlite3* db);
sqlite3* GetDatabase();

//lua hooks
lua_State* SetLuaState(lua_State* L);
lua_State* GetLuaState();

//The constructor & destructor are default, and private
//The singleton template class is declared friend

Theoretical Solution

The only technical drawbacks are the parameter lists of Create() and Load(). Otherwise, a templated *Manager class is perfectly viable. Here's my outline for it.

template<typename T>
class Manager : public Singleton<Manager<T>> {
public:
    //list all above methods as virtual except Create() & Load()
    //some methods, particularly those requiring database access, are declared pure virtual
private:
    std::map<int, T> container;
    //etc.
};

There's no guarantee this would be 100% perfect, since the RoomManager class will likely require other systems, like room management, etc. Nonetheless, this is still an OK template to follow.