The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

How to avoid passing references among several objects

Hi all

I have this situation in a big Java system: there are some objects that offer services used by many other objects (are utility objects like a logger, for instance). I will call each of such objects a "service".

At present time, I have to pass all those services to objects' constructors so that I have BIG constructors and I would like to simplify them.

I have two design restrictions: (1) the methods these service offer can't be implemented as static methods (because they are defined as interfaces) and  (2) there might be more than one instance of each service and different objects require a reference to a particular one.

Maybe the obvious solution is to create a "factory" object with references to all the services and a lot of getter methods and pass this only object to the constructors, but for some reason, this hurts my sense of aesthetics.

Any suggestion will be appreciated.
Pablo Send private email
Tuesday, June 03, 2008
 
 
Your basic tactic is sound. I know this is the case, because I do it too ;)

What I do (albeit in C++/C#) to cut down on the number of arguments is simply package the args up into a struct or class, pass that into the constructor, and have it either store off those services that it needs or simply take a copy of the whole args object and subsequently use its members directly.

In a sense, this buys you nothing, but it does cut down on the amount of typing, and that's always beneficial.
Tom_
Tuesday, June 03, 2008
 
 
Unfortunately, as ever, my post doesn't have full effect on my mind until it is displayed in a proportional font. I apologise for suggesting the very solution that you dismiss.

(I was bearing your post in mind as I wrote, but I only recalled the technical term "Factory" -- which to me means something very different...)
Tom_
Tuesday, June 03, 2008
 
 
I would prefer having a registerXService(IService) method on each client object instead.
hobit Send private email
Tuesday, June 03, 2008
 
 
<quote>
In a sense, this buys you nothing, but it does cut down on the amount of typing, and that's always beneficial.
</quote>

Not so fast.

Sure, you reduce typing. The usual cost of that is clarity. That's a BIG minus, in my book.

You only have to type that code once or twice. It will probably be read by others a lot more than that. It feels like optimizing for typing is attacking the wrong problem.
Bruce
Tuesday, June 03, 2008
 
 
First, I would avoid pass by reference parameters as in many languages, you are not passing a pointer to an object but a pointer to a variable, and that can be dangerous, as you could end up with two uncollected objects on the heap when you are done. Have you thought about caching, application-level variables, and other in-memory collections that can be accessed over time?
Ranger
Tuesday, June 03, 2008
 
 
Don't rule out the "factory" approach just yet. You just need a smarter factory.

What you're describing is a textbook usage of a Dependency Injection container. Since you're in the Java space, check out Spring or PicoContainer or one of many others that I'm sure are out there.

Look at http://martinfowler.com/articles/injection.html for a description of what DI is and how to use a container.
Chris Tavares Send private email
Tuesday, June 03, 2008
 
 
+1 to dependency injection.
sensible
Wednesday, June 04, 2008
 
 
"What you're describing is a textbook usage of a Dependency Injection" (Chis Tabares)

Yeap, I've realized this already. Actually, the very idea of these "service" objects that implements some interface aims precisely to that goal.

Problem is that I don't want to open yet another complexity from in my development int his point and wanted a simper solution (a simple yet intelligent factory, so to speak). However, maybe "I can run but I can't hide" from the dependency injection issue.

I probably will apply what I call the "context pattern", that basically says that some objects which have dependencies given from an execution context should be executed with (or "within") a "managed environment" or "container" which gives it access to such dependencies and that this environment should be passed in the object constructor. I've applied this "pattern" before, but was kind of reconsidering it in favor of dependency injection, but maybe I can mix both approaches (the environment can get the dependencies via dependency injection).

Thanks for the comments.
Pablo Send private email
Wednesday, June 04, 2008
 
 
Holly crap! sorry for so many typos in my previous post guys. Here is a cleaner version.

"What you're describing is a textbook usage of a Dependency Injection" (Chris Tavares)

Yeap, I've realized this already. Actually, the very idea of these "service" objects that implements some interface aims precisely to that goal.

Problem is that I don't want to open yet another complexity front in my development at this point and wanted a simpler solution (a simple yet intelligent factory, so to speak). However, maybe "I can run but I can't hide" from the dependency injection issue.

I probably will apply what I call the "context pattern", that basically says that some objects which have dependencies given from an execution context should be executed with (or "within") a "managed environment" or "container" which gives it access to such dependencies and that this environment should be passed in the object constructor. I've applied this "pattern" before, but was  reconsidering it in favor of dependency injection. Maybe I can mix both approaches (the environment can get the dependencies via dependency injection).

Thanks for the comments
Pablo Send private email
Wednesday, June 04, 2008
 
 
<quote>
First, I would avoid pass by reference parameters as in many languages, you are not passing a pointer to an object but a pointer to a variable, and that can be dangerous, as you could end up with two uncollected objects on the heap when you are done. Have you thought about caching, application-level variables, and other in-memory collections that can be accessed over time? Ranger
</quote>

Since the OP indicated it's about a Java application, none of that is relevant.

Wednesday, June 04, 2008
 
 
It was this need for dependency injection that made me start to use Spring, and very useful it has proven. Id recommend giving it a look.
AH
Friday, June 06, 2008
 
 
I you want a lighter solution, take a look at Guice (though some say it is less flexible).
JB Send private email
Saturday, June 28, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz