|
If you're interested in loose coupling in your design, I would definitely take a look into Dependency Injection. BTW - what you described initially sounds to me like a variation on the Mediator pattern.
|
|
|
|
|
Pete O'Hanlon wrote: I would definitely take a look into Dependency Injection
I did a search and found Martin Fowler's article on Dependency Injection.[^] Iteresting read.
My situation is similar but not exactly the same to that described in the article, but I think the principle is still applicable, more or less.
Basically, I have one class that offers a set of services, mainly simple notifications when certain things happen within the application. Next, I have a group of class's that use these services. Which services are used can vary from class to class.
The problem I run into is when I start trying to manually wire things up. So I've got my Service over here and my Clients over here, and I have to remember which services a client needs when wiring them together.
The solution that I've settled on is to pass the Service to each Client when it is created. Then the Client can subscribe to those services it needs. The containing class, the one containing all of the Clients, doesn't have to know how to hook up Clients to the Service; it just pass the Service along.
I think I like this solution. It has greater coupling in that Clients are familiar with the Service, but this can be mitigated by hiding the Service behind an interface, which I think is what Dependency Injection does, more or less.
Anyway, thanks for the reply. I'd heard of Dependency Inversion but not Dependency Injection.
|
|
|
|
|
|
I've already seen your article. There's no need to spam it.  And I've done a lot of Dependency Injection, so I don't need a link to an article on it, hence the reason I recommended it.
|
|
|
|
|
Pete,
May be I was not very clear . Actually not only I agreed with your opinion, but I meant to add into your concise reply by informing Lelie who wrote "I'd heard of Dependency Inversion but not Dependency Injection", that is why I referred to a link! Perhaps it was"Inversion of Control"  that was intended.
Fakher Halim
modified on Thursday, July 17, 2008 4:00 PM
|
|
|
|
|
Fakher Halim wrote: Perhaps you meant "Inversion of Control"
Nope - I meant Dependency Injection, as featured in my original post, and which he found in his search. Anyway, no harm done.
|
|
|
|
|
Thanks!! it should be just a typo! 
Fakher Halim
|
|
|
|
|
Pete O'Hanlon wrote: BTW - what you described initially sounds to me like a variation on the Mediator pattern.
You mean this initial statement?
Leslie Sanford wrote: I was reading
led mike
|
|
|
|
|
led mike wrote: You mean this initial statement?
Leslie Sanford wrote:
I was reading
|
|
|
|
|
Good morning!!
What's the design pattern whereby you have to go through a certain class to get an instance of another?
E.G,
I have a class called Devices, and classes Valve, PID, ControlVlv and Pump.
I don't want to be able to instantiate Valve, Pump etc without going through Devices (which will return a collection of said classes).
But I want to be able to use said classes throughout the app.
Does that make sense?
I'm sure I've done it before....
Thanks,
|
|
|
|
|
Hi,
sounds like a Factory to me.
|
|
|
|
|
Ye ah I thought that, just can't seem to find the right one!
|
|
|
|
|
You've got the right surname to be talking about patterns.  Sounds like you need to consider using something like the Abstract Factory pattern.
|
|
|
|
|
This one has puzzled me before.
Valves, pumps, and the like sound very concrete, yet they want to call it an abstract factory?
|
|
|
|
|
I know. It's a really crappy name. Really really crappy.
|
|
|
|
|
|
Nooooo. It is a good name, though just as good and maybe better would be static factory. The factory itself is usually a class with only static methods, so it should be static (or abstract, though static is perhaps the more academically pleasing choice since it's not intended as a base class for concrete factories but rather just a bunch of static members relating to the same thing). So even though the products of the factory are concrete, the factory itself isn't.
Pump p = Factory.CreatePump(...);
not
Factory f = new Factory();
Pump p = f.CreatePump(...);
Normalement.
|
|
|
|
|
This[^] message explains my problem with the name. I prefer the static name you suggest though - it sounds better.
|
|
|
|
|
Luc Pattyn wrote: yet they want to call it an abstract factory?
What are you guys talking about? Isn't the pattern supposed to use the implementation of an abstract class for the factory and the user derives from it implementing the concrete factories? Or am I not remembering the pattern correctly?
led mike
|
|
|
|
|
You are remembering it correctly. It's just a name that I have a problem with just because it sounds like you can directly instantiate abstract classes. I'm not sure what they should call it, but I've had staff being confused about this when they complain about their code not working because it's abstract.
|
|
|
|
|
Pete O'Hanlon wrote: but I've had staff being confused about this when they complain about their code not working because it's abstract.
Sorry to hear that. On the bright side at least you work with people that use the word "Abstract"! That's more than I can say! 
led mike
|
|
|
|
|
led mike wrote: at least you work with people that use the word "Abstract"! That's more than I can say!
Ouch. 
|
|
|
|
|
Dude, it looks like you are being stalked by a 2.0 voter? Even I don't have a stalker! 
led mike
|
|
|
|
|
led mike wrote: Dude, it looks like you are being stalked by a 2.0 voter? Even I don't have a stalker!
Damn. I'm not even worthy of a Univoter.
|
|
|
|
|
I often accidentally vote 2.... when a little spaced out it is far too easy to think, as you arrive at the last message, that those numbers represent pages. So I try to navigate to page 2, and get "thank you for voting"..!
I must apologize to any victims (none today tho). 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
