Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Share Data Among Objects Using the Monostate Design Pattern

When you share data among users via a file, you put down the welcome mat for versioning problems, or worse, a security breach. Solve this problem using a simple design pattern.




Full Text Search: The Key to Better Natural Language Queries for NoSQL in Node.js

ertain applications need to share data among different users or among distributed instances of the same application. Using a file to store the shared data isn't an ideal solution due to security and data integrity reasons. This month I will suggest another solution based on the monostate design pattern.

How can you ensure that all users of the same application access shared data safely?

Use the monostate design pattern to ensure safe and synchronized data sharing.

Step 1: Design
Imagine a large department store that has different departments for multimedia, clothes, and cosmetics. Such stores often enable tourists to pay in their own currencies. How can you ensure that every department has access to the same exchange rate table? Using a shared physical file might cause security and data-integrity problems. For example, the filename and its path might change; worse yet, users might access an outdated version of the file. Besides, this is an implementation detail that should be hidden from end users.

A preferable solution is to encapsulate the exchange rates in a class. You want to ensure that every user and application module gets a private object instance of the class in question while ensuring that these objects always share the same state. Furthermore, any change in the state of the class should propagate to other objects automatically and immediately. This is exactly what the monostate design pattern provides.

A monostate class is a class that implements the monostate design pattern. A monostate class contains only static data members and member functions. This way, all of its object instances share the same state.

Step 2: Implementation
We will create a monostate class, called Exchange, whose static data members represent the exchange rates of a various currencies, say Euros per $1 U.S., etc.:

class Exchange { private: static double Euro; // Euros per $1 U.S. static double GBP; // British pounds per $1 U.S. static double Yen; // Yens per $1 U.S. //... };

The definitions of the static members outside the class also initialize them:

double Exchange::Euro=0.8630; // Euros per $1 U.S. double Exchange::GBP=0.6017; // British Pounds per $1 U.S. double Exchange::Yen= 119.34; // Yens per $1 U.S.

In the real world you'd probably use a function that reads the current exchange rates from a remote server or a database to initialize the data. For example:

double Exchange::Euro= trade_server.get_euro_rate(now); // Euros per $1 U.S. //other currencies

The class also contains member functions that exchange these currencies to and from U.S. dollars:

class Exchange { // public: double Euro_to_USD(double euros) const { return euros/Euro;} double US_to_Euro(double us_dollars) const { return us_dollars*Euro;} double GBP_to_USD(double pounds) const { return pounds/GBP;} double USD_to_GBP(double us_dollars) const { return us_dollars*GBP;} // };

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date