|
|
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). 
|
|
|
|
|
Hi,
We have a whole bunch of PC's that monitor other machines (We're talking about 30-40 monitors PC's tracking 1 machine each)
I'm planning on writing a 'dash board' app that provides a manager with a live view of the state of all the machines. I can't seem to think of a good way to architect it.
Options:
1) PULL - Monitor app exposes a web service (or some other connection type, remoting or whatever) and the dash board app calls it to get the current status. Problem, will need to be called around once a second to be live enough, this could be an issue if lots of managers have the app open watching the status. number of pull requests required will be (running_dash_board_app_count * monitor_app_count)
2) PUSH - Dash board app subscribes in some way to notifications. Monitor app pushes out notifications (via web services/remoting whatever) to dash board app. Again, same issue, notifications will need to be pushed out around once a second, so the network traffic could get really high. Notifications messages will again be (running_dash_board_app_count * monitor_app_count).
What other options are there. I don't want to flood the network with stacks of traffic just pushing or pulling status updates. This doesn't scale at all, say we had 20 managers, each new machine will add 20 new connections.
Simon
|
|
|
|
|
Push: Monitor app is stateful, has to handle registrations, throttling and all sorts of BS. Saves a request packet on updates, perhaps 1% of the total bandwidth.
hence, Pull: Use this method.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
