When I designed my database class for my current application project, I had to ask myself how to actually be able to access this class from anywhere in my application, from every form, class and whatnot. Of course I could just create an instance of my database class on the spot, just where I need it, but that’s a very inefficient way. Eventually I end up creating dozens of objects that, after all, contain the same data.
One solution might be static classes? It’s not that easy. When you already wrote your complete class in a non-static way, its difficult to turn it static. (By the way, in C++ static classes are no more than normal classes with just all member variables and functions declared static, you can’t create a static class by itself) Problem with these static classes is, that static functions can only access static variables and other static functions, as static members are not bound to any object instance, hence don’t have access to the object’s innards. This can conflict with the usual class architecture.
A much simpler way, without the need to completely reconstruct your class, bases on the Singleton Pattern :
In software engineering, the singleton pattern is a design pattern used to implement the mathematical concept of a singleton, by restricting the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system. The concept is sometimes generalized to systems that operate more efficiently when only one object exists, or that restrict the instantiation to a certain number of objects (say, five). Some consider it an anti-pattern, judging that it is overused, introduces unnecessary limitations in situations where a sole instance of a class is not actually required, and introduces global state into an application.
In C++ it also serves to isolate from the unpredictability of the order of dynamic initialization, returning control to the programmer.
The key aspect of the Singleton Pattern is that you create just one single instance of the object in a central class of your project. To get access to your object, you then retrieve the pointer of the instance from the class you instantiated it in. This could look like illustrated in the picture below.
In this illustration, the to-be-single object is of the DatabaseMgr class, contained in the Application object MyApp, and retrieved through it by other classes.
Explaining the Magic
In bada projects, the central class of every application is the
Osp::App::Application class itself, which is present in every bada project of course. If you want to use a single database object like me for example, that deals with the I/O work for your database files, lets call it
myDb, you declare the DatabaseMgr object as a class member in the header file and initialize it in the OnAppInitializing method.
Fortunately, the Application class offers the static function GetInstance(), which returns a pointer to the application itself:
static Application* Osp::App::Application::GetInstance (void) [static] Returns the application's instance pointer. Returns: An Application instance pointer, if successful null, if it fails See also: Application ()
As this is a static function, this can be called from anywhere within your bada project, from whatever form or class you want! For the example depicted in the diagram, with the Application class MyApp, the single object myDb of the DatabaseMgr class and a random class or form you want to access DatabaseMgr from, you can gain access in 2 simple steps:
Get the Application instance
MyApp *appInstance = static_cast<MyApp *>(MyApp::GetInstance());
Do not forget to call
#include "MyApp.h", or your application class respectively, in the preprocessor
Access the Pointer
DatabaseMgr *dbInstance = appInstance->myDb;
or you can directly call DatabaseMgr functions through the appInstance pointer, for example:
appInstance->myDb->InsertCell(key, columnId, value);
That’s it! Now you got full access to your crucial object from anywhere in your project.