Creating a pluggable architecture
A project I'm working on needs to be split up into a series of interfaces so that, for example, implementing Interface1 will have a set of methods which it executes, Interface 2 has a different set and so on. Up to this part is fine.
The part I'm struggling with (I'm completely new to this concept) is that we have lots of objects which gather information from a database, and then performs some calculations and produces some output depending on which interface it implements. However, the information could be common to several interfaces, and splitting it up in such a way that there exists no cross-dependencies (if that makes sense) is something I have no idea about.
I've googled and not found much, so if anyone could point me in the direction of a tutorial, or give me some advice on the best way to approach this problem I'd be very grateful.
A little bit of sample code would help.
That's a very very generalised description of your problem, to be honest. Could you be more specific?
What does information have to do with interfaces, by the way?
I'm afraid it is a very generalised description but that's the point at where I am at the moment...
The point of the interfaces is essentially to call them when required i.e. the user makes a request for a certain calculation to be performed, some class associated with that interface will implement it, do some calculations and then spit out some data. That's how I understand it anyway.
> I'm afraid it is a very generalised description but
> that's the point at where I am at the moment...
>
> The point of the interfaces is essentially to call
> them when required i.e. the user makes a request for
> a certain calculation to be performed, some class
> associated with that interface will implement it, do
> some calculations and then spit out some data. That's
> how I understand it anyway.
Sounds good. What's the problem?
How I'd go about making this into a 'pluggable' architecture so to speak i.e. if there are any tutorials which would give me more of an understanding of the area. Or at least how I might go about trying to identify dependencies on the different data objects within the project.
What do you mean by "pluggable" in this context? Sounds pretty pluggable already
Or was "it should be pluggable" a requirement brought up in some meeting? If so, call another meeting to pin down exactly what was meant by that. It's often a meaningless term thrown about by non-techies or people who don't really understand what it actually means
> What do you mean by "pluggable" in this context?
> Sounds pretty pluggable already
>
> Or was "it should be pluggable" a requirement
> brought up in some meeting? If so, call another
> meeting to pin down exactly what was meant by that.
> It's often a meaningless term thrown about by
> non-techies or people who don't really understand
> what it actually means
I get that impression too, but I don't have much experience as a developer so I've no right to shoot my mouth off unless I genuinely know what I'm talking about, which clearly I don't here. I'll post if I have any more questions, thanks anyway.
> > What do you mean by "pluggable" in this context?
> > Sounds pretty pluggable already
> >
> > Or was "it should be pluggable" a requirement
> > brought up in some meeting? If so, call another
> > meeting to pin down exactly what was meant by
> that.
> > It's often a meaningless term thrown about by
> > non-techies or people who don't really understand
> > what it actually means
>
> I get that impression too, but I don't have much
> experience as a developer so I've no right to shoot
> my mouth off unless I genuinely know what I'm talking
> about, which clearly I don't here.
But you do have the right to ask someone to clarify what they mean. You don't need to know much to know that "pluggable" is a very vague requirement. It's not obligatory to be an expert before questioning someone else's idea
> I'll post if I
> have any more questions, thanks anyway.
No problem
