Im a little confused about your post.. How else am I supposed to share the options across the different classes in my program? I thought this is the right approach towards that kind of problems in c++.Originally Posted by medievalelks
I think the design I mentioned is good because in case options change, I dont have to change the data in each class separetly (if each class holds the options it needs).
Last edited by l2u; 04-17-2008 at 09:45 AM.
It's hard to tell without a more concrete example. What are these "options"? Are these program-wide settings that you are managing with the options class? If so, how are they initialized?
The way I've handled this is to create a singleton that manages all program settings, which are read from a text file and stored in a std::map. Clients of the class fetch object values by calling a getString() or getDouble() member function on the singleton, which returns the value of the setting or option.
I dont like singleton design approach because I want to be more object oriented - to be able to have multi-session program (different options for same tasks).
What is not OO about singletons?
Anyway, that solution is out since you want multiple instances of the options. In any event, I would hide options behind a queryable interface so you don't have multiple objects fiddling with what is essentially a POD. So instead of checking if options.FullScreen is true in different places, have them call OptionInterface.isFullscreen().
I like my own class member function interface better. It essentially makes it possible to use class members as PODs, yet they are object oriented in sense that you can wrap functionality in function calls. Essentially, it's like set/get.
I posted it on the 1st page.
