|
|
I'm putting together what is essentially a template for listeners for a Message Queue server. The process I would like to have is the following
1) Connect to correct Message Queue
2) Listen for Message
3) Retrieve Message when it arrives
4) Process the message
5) Return results to the return queue
The way I would like to build the template is that all the steps but step 4 are handled by the template. Ideally I could then write individual libraries that could be plugged in to handle the processing of different types of messages to build out the individual listeners. I could script the builds for the all the listeners so if a change was made to the template I could run the script and rebuild all listeners at once or if there is a change to a individual listener I could just rebuild that listener.
Basic OOP seems to have fled my brain this today and I cannot think of how to do this. I'm thinking that I will need to use reflection to load the different dlls at runtime and then separate the listener executibles into their own directories so they can be placed with the correct library. Does this sound right? It seems that there should be an easier way but it escapes me at the moment.
Thanks for any help you can give.
The hurrier I go the behinder I get....
|
|
|
|
|
I'd suggest looking at Microsoft Extensibility Framework[^] instead of rolling your own using Reflection...
A positive attitude may not solve every problem, but it will annoy enough people to be worth the effort.
|
|
|
|
|
Hi,
In his recent blog[^] Uncle Bob come up with a situation that explains interface is harmful. Here is the code snippet taken from his blog.
public class Subject {
private List<Observer> observers = new ArrayList<>();
private void register(Observer o) {
observers.add(o);
}
private void notify() {
for (Observer o : observers)
o.update();
}
}
public class MyWidget {...}
public class MyObservableWidget extends MyWidget, Subject {
...
}
Here he explains that to implement Observer pattern done correctly, compilers must allow multiple inheritance.
So my question is why don't the MyObservableWidget implement using dependency injection like below to avoid multiple inheritance with greater degree of separation of concerns?
public class MyObservableWidget extends MyWidget {
private Subject subject;
public MyObservableWidget(Subject subject) {
this.subject = subject;
}
}
Of course the Subject class should be an abstract class. Please let me know your thoughts.
Thanks,
Pop
|
|
|
|
|
"Ivory tower theorizing considered harmful." -- DMR
|
|
|
|
|
|
I gather that this article needed the help of a proctologist with a torch.
|
|
|
|
|
Pete O'Hanlon wrote: with a torch
Or maybe just an ear-trumpet? 
|
|
|
|
|
Was that a brainless question? 
|
|
|
|
|
Not completely, but it's more a Lounge type discussion, than a technical question.
|
|
|
|
|
Oh that explains the hatred towards my question. But I was not trying to degrade that article. All I meant about the technical aspects of that idea. Sorry for my ignorance; I thought my solution can overcome the problem specified in the article.
Thanks,
Pop
|
|
|
|
|
I think the "hatred" was directed at Uncle Bob, not at you.
|
|
|
|
|
Thank you! 
|
|
|
|
|
Was there hatred towards your article? I was actually commenting that o' Uncle Bob seemed to have pulled his argument out of his posterior.
|
|
|
|
|
|
Hi,
Thank you for the blog link.
You propose what is called mixin, which is really the go to solution to avoid bloated inheritance hierarchies.
The good thing about mixin of Subject is that you hide functionality and avoids to duplicate the code in Subject.
The bad thing is that you still need to duplicate the code that calls Subject aka relaying.
DI with mixin is also good since you make the dependency known to the outside. This opens up for implementation replacement from the outside and gives better transparency.
However, Uncle Bob really wants to hide stuff and use inheritance to avoid ANY code duplication and he can't do that in a single inheritance language.
I love interfaces because they form a specification layer without any implementation details. I love abstract classes because they can be implementation templates for concrete classes. I do not want to mix the 2 concerns - at all. And it IS a tad annoying when you need add mixin in you abstract classes to avoid code duplication.
I wouldn't mind multiple inheritance, if the language/compiler could manage diamonds in a consistent and obvious way (No, C++ doesn't). The class hierarchy is however implementation - not specification (IMHO). Uncle Bob doesn't address that view on the interface keyword.... and I am not sure the interface keyword had that view in mind when invented.
|
|
|
|
|
Keld Ølykke wrote: No, C++ doesn't
I think it does. Why do you say it doesn't?
Keld Ølykke wrote: class hierarchy is however implementation - not specification
Agreed. Hence, I don't think interfaces are "harmful", but what Uncle Bob was really complaining about is not being able to have multiple base classes.
However, I think true separation of concerns would use neither DI nor inheritance to do his observer pattern but rather a separate "observer manager" class that does both the observing and registration/deregistration.
#SupportHeForShe If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
Well, by not consistent I mean that you can end up with compiler accepted code, but it is unknown what it will do. The "dreaded diamond" refers to the situation where class C inherits from 2 classes B1 & B2 that both inherits the same base A. C will have 2 copies of all fields from A and at runtime it is undefined which copy you address.
|
|
|
|
|
Ah, sure, I see. But you can solve that by using "virtual" inheritance. Then there's only one instance of A. Of course, you can't always do that when using third-party libraries.
#SupportHeForShe If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
Yes. If C++ was a game I would call it a tad unforgiving
|
|
|
|
|
this question is logical type. there is single data centre with single firewall and to handle 5 lakh clients from this single data centre i want a technique in which i dont have to mess any thing with data centre but infact some kind of delay must be generated at clients side only in order to avoid load or traffic on data centre
|
|
|
|
|
Impossible. How can client systems know when to delay and when it is OK to connect? If your system cannot be tuned to handle large load then you need to employ a network engineer to help you.
|
|
|
|
|
Can somebody explains how I can implement properly Open/Close principles in Python? Since Python class does not supports method overloading or function overloading like in C++, C# or Java. In. e.x.:
if I created class which calls connectivity:
class Connectivity(object):
def connect(self, ip, port):
and later If i want to add connection time out argument for connection method I cannot keep Open/Close principles like this:
class Connectivity(object):
def connect(self, ip, port):
def connect(self, ip, port, timeout):
So what I should do in this case? How I can follow properly SOLID principles in Python? Thank you in advance.
|
|
|
|
|
Disclaimer; I have never touched Python.
If C# had no function overloading I'd be passing an object, as opposed to a list of parameters. For example;
class ConnectArgs
{
public object self { get; set; }
public string ip { get; set; }
public int port { get; set; }
}
class ConnectArgsExt: ConnectArgs
{
public int TimeOut { get; set; }
}
With the method accepting it like below;
public connect(ConnectArgs args)
Since you defined a class, I assume Python has classes and supports inheritance. That way you needn't change the interface, but you'd still have the option to extend it with a new parameter if required.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
You need to create a new method with a different name, or, better still, a new class that inherits from this class. You can then override the method, but still call the base method if necessary. Something like:
class Connectivity(object):
def connect(self, ip, port):
class NewConnectivity(Connectivity):
def connect(self, ip, port, timeout):
Connectivity(self, ip, port)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
