|Think about Loose Coupling|
Re: Reblessingby Sherlock (Deacon)
|on Jun 21, 2001 at 17:58 UTC||Need Help??|
Obviously, there is going to be benefits and drawback to either approach. What I think you want to do is figure out which one has the most important benefits and the least significant drawbacks for your application. I'll try to explain my take on either architecture and you can conclude whatever you'd like from there.
Case 1: Use of a Connection Object
This architecture gives you more flexibility. You're basically creating your own API for your application. (At least to some degree.) You're saying that if all objects that need to access the server use these methods, they will be supported by the connection object. The connection object then handles and data requests that are made of the server. The bonus to this is that if your server needs to change, all of your "outer" objects (those that talk to the connection object) can be totally ignorant of those changes. They're still chatting happily away with the connection object.
So what's the downside? Imagine you want to ask a friend of yours if they want to go out for a round of golf? Is it faster to ask your friend directly or to ask someone else to ask your friend for you? Obviously, it'd be faster to ask your friend driectly. This analogy is trying to point out that the first architecture is going to have higher overhead - things are just going to take a little longer. If speed isn't of critical importance in this application, this probably isn't a big deal, but if you're crunched for milliseconds, this could be a crucial decision.
Case 2: Talking directly to a server
In the second architecture, you're cutting out the middleman, which in some cases is very good. The overhead that I was discussing before is gone. By speaking directly to the server, you get instant feedback which can be very important to time-critical applications.
The downside (as you seem to have already spotted) is that if your server ever needs to change, you need to change all of the objects that talk to the server (unless you can manage to support all of the same methods used to speak to your server). This takes away some of your flexibility at the cost of speed. If you don't plan on changing this application ever *COUGH* WARNING! EVERYTHING CHANGES *COUGH*, I think you could get away with this approach and save some time, but if your server hasn't been very well thought out and planned, it may change. The more changes it needs, the less feasible this solution becomes.
As far as I can tell, this is a simple question of "What's more important? Speed or Flexibility? That's a question that you need to answer according to your application. This answer might vary from this application to the next one you write, as well.
I'd like to take a second to discuss your point on OO design, though. You said:
Since I tend to think that OO should represent the real world and how we think about it, I find model two more plausible. I wouldn't ask a connection about the state of a server, I would ask the server!
Indeed, OO design is supposed to model the real world, but not to the point where it hinders your ability to design a robust and flexible system. The real "selling point" of OO is that you can pick up an object from one system and drop it into another, just as you can pick up one "real world" object and drop it somewhere else. Could you grab that connection object in this system and use it elsewhere - I would sure hope so! I've used many such objects in my experience. As long as the methods it uses are well thought-out, you should be able to grab that object and use it anywhere with only minimal changes - at least the interface should remain constant. If you can achieve this level of reusability in your code, you've done an excellent job of OO design. So, even if your design doens't exactly match what you might do in the real world, that doesn't mean that it's a bad design.
I guess you can probably tell which solution I lean toward - I generally opt for greater flexibility in my applications. The one thing you can generally be sure of is that things will change - the more you plan for that, the easier your life will become. Of course, if you're piched for time, sometimes you need to throw that flexibility out the window and hope it doesn't bite you in the a** later. ;)
Well, that's just what I think about the situation - you can make your own conclusions about your particular application. I'd be very interested to see which architecture you decided to use and why you used it, though.
Skepticism is the source of knowledge as much as knowledge is the source of skepticism.