advertisement
Login | Register   
  Include Code  Search Tips
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Five years ago, design patterns were the hottest buzzword in the software development world. Today it seems that programmers are less enthusiastic about them. What's your experience with design patterns? Are they a fad or a solid framework that has improved software development time and quality?
Partners & Affiliates
advertisement
advertisement
advertisement
advertisement
Average Rating: 2.5/5 | Rate this item | 17 users have rated this item.
Share Data Among Objects Using the Monostate Design Pattern (cont'd)
Step 3: Usage
Now that you've seen the code for the class, I'll step through how it works. Suppose a British tourist visits the cosmetics department and decides to purchase a perfume that costs $99.95. She prefers to pay cash, in pounds. The attendant types the amount 99.95 in the "Exchange $ to £" dialog box. Under the hood, the application does something like this:

int main()
{
Exchange xcg; //cosmetics dept.'s private object
double pounds=xcg.USD_to_GBP(99.95);//convert $99.95 to GBP
cout<<"equivalent amount in British pounds: " <<; pounds << endl;
}
advertisement
The program's output is as follows:


You probably want to round the amount 60.1399 to 60.14 automatically. You can define a policies class that will write the user interface for the rounding. These policies may include rounding schemes, say up to the closest penny or in units of 5 or 10 pence. These policies should not be included in the Exchange class as it is responsible for representing the raw exchange rates only. Furthermore, while exchange rates change on a daily basis (or even by the hour), store policies are more stable. Keeping your Exchange class independent of fluctuating exchange rates will make it more stable and easier to maintain.

Monostate Muscle
I haven't shown the real strength of the monostate pattern yet. Suppose our store updates the exchange rates every hour, according to quote prices of a certain bank. To change the rate we add another class called Admin, which is a friend of class Exchange. The new exchange rate propagates swiftly to all instances of Exchange.

class Admin;
class Exchange
{
friend class Admin;
//
};
class Admin
{
public:
Admin(const string &password) {} //authorize
void set_EURO(double euros) const {Exchange::Euro = euros;}
void set_GBP(double pounds) const {Exchange::GBP = pounds;}
//
};
Suppose the British pound exchange rate is now 0.62. The system administrator updates it like this:

Admin admin("mypassword");
admin.set_GBP(0.62);
From this moment, every instance of the Exchange class is aware of the new exchange rate. If another British lady decides to buy the same perfume, she'll now have to pay 61.97 pounds:

pounds=rates.USD_to_GBP(99.95);
cout<<"equivalent amount in British pounds: " << pounds << endl;


Magnificent Monostate
The monostate pattern isn't included in the de-facto pattern catalog because it was developed later. In terms of its goals, monostate is similar to the singleton pattern, albeit much simpler in terms of implementation and usage.

The use of static data members and member functions ensures that the same state is shared by all objects of the same class, regardless of their creation time. Changing a static member's value enables you to update the objects' state immediately and automatically. The implementation of the monostate class shown here isn't thread safe. However, with slight modifications you can turn it into a thread-safe class.

Previous Page: Design  
Danny Kalev is a system analyst and software engineer with 15 years of experience, specializing in C++ and object-oriented analysis and design. He was a member of the ANSI C++ standardization committee between 1997-2001. Danny is the author of ANSI/ISO C++ Professional Programmer's Handbook and the C++ Section Leader for DevX He can be reached at dannykk@inter.net.il
Page 1: DesignPage 2: Usage
Please rate this item (5=best)
 1  2  3  4  5
advertisement