I've got a value that many objects need. For example, a financial application with different investments as objects, and most of them need the current interest rate.
I was hoping to encapsulate my "financial environment" as an object, with the interest rate as a property. But, sibling objects that need that value can't get to it.
So how do I share values among many objects without over-coupling my design? Obviously I'm thinking about this wrong.
I've got a value that many objects need.
This is a design smell. It's uncommon that many objects need to know about something. That said, the current interest rate is a fairly good example of exceptional circumstances. One thing to worry about is that there's rarely the interest rate. Different financial instruments use different rates. At the very least, different locales use different 'standard' rates. Further, to aid in testing and reporting, you'll usually want to pass in a rate since you don't want to use the current rate there. You want to use the 'what if' or 'as of reporting date' rate.
So how do I share values among many objects without over-coupling my design?
By sharing them, not having them all refer to a single instance. Passing the same thing around is still coupling to a degree, but not over coupling since something like the current interest rate is needed as input to a variety of calculations.
In this particular instance I would use the Singleton Pattern. The FinancialEnvironment would be the object all the other class libraries are aware of, but would be instantiated by the Singleton. Ideally you would then send that instantiated object to the various class libraries.
For example:
The other classes are only tied together through the Entities class library, they accept an instantiated FinancialEnvironment object. They don't care how it was created, only the service layer does, all they want is the information. The singleton could also be smart enough to store several FinancialEnvironment objects, depending on the rules for the local as @Telastyn pointed out.
On a side note, I am not a huge fan of the Singleton Pattern, I consider it a code smell, as it can be misused very easily. But in some cases you need it.
If you absolutely, positively must have a global variable then implementing the Singleton Pattern as described above would work. However, I am not a big fan of this, and based on the comments from my original post, several other people are not either. As something as volatile as a InterestRate, a Singleton may not be the best solution. Singletons work best when the information doesn't change. For example, I used a Singleton in one of my applications to instantiate performance counters. Because if they do change then you must have logic in place to handle the data being updated.
If I were a betting man I would bet the interest rate was stored somewhere in a database, or it was retrieved via a web service. In that case a Repository (data access layer) would be recommended to retrieve that information. To avoid unnecessary trips to the database (I am not sure how often interest rates change, or other information in the FinancialInformation class), caching could be used. In the C# world Microsoft's Caching Application Block library works very well.
The only thing that would change from the example above, would be the various classes in the service layer that need the FinancialInformation would retrieve from the Data Access Layer instead of the Singleton instantiating the object.
Singleton is a global with OO syntactic sugar and a crutch for the lazy and weak minded. Singleton/global is the absolute worst way to tightly couple your code to something that will be a cancer later on when you realize what a colossally bad idea it was and why everyone says they are!
– user7519
Jul 10 '12 at 3:07
Configuration Files?
If you have values that are used "globally", please put them in a configuration file. Then each system and subsystem can reference this and pull the keys needed, make them read-only.
I'm speaking from the experience of one who has about a month of maintenance on a good sized (~50k LOC) project that we just released.
I can tell you that you probably don't really want a global object. Introducing that sort of cruft provides many more opportunities for abuse than it does help.
My initial suggestion is that if you have several different classes that need a current interest rate then you probably want to just have them implement an IInterestRateConsumer or something. Inside that interface you'll have a SetCurrentInterestRate(double rate) (or whatever makes sense), or maybe just a property.
Passing an interest rate around is not actually coupling - If your class needs an interest rate, that's part of its API. It's only coupling if one of your classes starts worrying about exactly how the other class uses that interest rate.
Martin Fowler has an article that talks briefly about how to refactor a static global into something more flexible. Basically you make it into a singleton then modify the singleton so that it supports overriding the class of the instance with a subclass (and if needed move the logic that creates the instance to a separate class that can be sub-classed, which you would do if creating the super-class instance then replacing it later is a problem).
Of course, you have to weigh the problems with singletons (even substitutable singletons) vs. the pain of passing the same object everywhere.
As far as the "financial environment" object - it's convenient to program on the first pass, but when you are done you have added some extra dependencies. Classes that just need an interest rate now only function when passed a financial environment object, which will make them difficult to reuse when you don't happen to have a financial environment object lying about. So I would discourage passing it widely.
Why not put the interest rate data in a central cache?
You can use one of several cache libraries, whichever suits you requirements best, something like memcached solves all you concurrency and code management problems and will allow your application to scale to multiple processes.
Or go the whole hog and store them in a database, which will allow you to scale to multiple servers.
In such situations I have successfully introduced (reused) the "context" term with sometimes multiple layers.
This means a singleton, thus "global" object store, from which these kind of objects can be requested. Codes that require them, include the header of the store, and use the global functions to get their object instances (like now, the interest rate provider).
The store may be either:
The bigger the system, the more usable the latter solution is, for a quite small risk of using the wrong enum. On the other hand, with languages that allow forward type declarations, I think you can use typed accessors without including all the headers in the store.
One more note: you may have multiple instances of the same object type for different uses, like sometimes different Language value for the GUI and for printout, global and session level logs, etc, so the enum / accessor name should NOT reflect the actual type, but the role of the requested instance (CurrentInterestRate).
In the store implementation, you have to manage the context levels and context instance collections. A simple example is web service, where you have the global context (one instance for all requests for that object - problematic when having a server farm), and a context for each web session. You can also have contexts for each user, who may have multiple, parallel sessions, etc. With multiple servers you should use a kind of distributed cache for such things.
When the request comes in, you decide which context level the requested object is, get that context for the call. If the object is there, you send it back; if not, you create and store it at that context level, and return it. Of course, synchronize the creation section (and publish it to the distributed cache). The creation can be configurable plugin-like, best with languages allowing creating object instances by their class name (Java, Objective C, ...), but you can do that in C as well with pluggable libraries having factory functions.
Side note: the caller should NOT know too much about its own contexts, and the requested object's context level. Reasons: 1: it is easy to make mistake (or "clever tricks") by playing with these parameters; 2: the context level of the requested might change later. I mostly connect context information to the thread, so the object store has the information without extra parameters from the request.
On the other hand, the request may contain hint for the instance: like getting interest rate for a specific date. It should be the same "global" access, but multiple instances depending on the date (and leading different date values to the same instance between rate changes), so it is advisable to add a "hint" object to the request, used by the instance factory and not the store; and a keyForHint to the factory, used by the store. You can add these functions later, I just mentioned.
For your case this is a kind of overkill (only one object is served in global level), but for a quite small and simple extra code right now, you get a mechanism for further, perhaps more complex requirements.
Another good news: if you are in Java, you get this service from Spring without thinking too much, I just wanted to explain it in details.
The reason NOT to use a global (or singleton) is that even though you initially expect to only have one value, it's often surprisingly useful to be able to use the same code multiple times in the same program, for instance:
I would make the interest rate a member of the "financial instrument" class, and accept that you have to pass it in to any member classses (either per-calculation, or giving them a pointer/hook to it on construction).
Things should be passed in messages, not read from a global thingy.
updatefunction that's called at each timestep? Can you post in pseudocode how your simulation operates? – James Jul 10 '12 at 2:19Singletonis a global with OO syntactic sugar on it and is a terrible solution that tightly couples your code in some of the worst ways possible. Read this article over and over until you understand it! – user7519 Jul 10 '12 at 3:10DateTimeas input and return a number as output. – rwong Jul 10 '12 at 4:17