On 06/28/2013 11:23 AM, Fraser Adams wrote:
Another good argument for modularisation is that it forces the hand in
terms of better decoupling. In the recent discussions on removing chunks
of code from the code base it's pretty clear that some things
"organically evolved" and have ended up creating some quite monolithic
artefacts.
Well put! This was the point I was trying to make.
As a trivial example, it was because the xml exchange was in a separate
library that the exchange registry was modified to allow registration of
different types of exchange rather than adding to the if/else clause in
declare (where for example the management exchanges have been added,
unnecessarily increasing coupling).
This is not to say that the better design *requires* dynamically loaded
modules, but as Fraser says, on occasion it 'forces the hand' in the
right direction.
Another example would be the 1.0 stuff I've been working on. I had to
introduce the ObjectFactory into the broker to allow different types of
object to be created via the generic management create/delete function.
Had the 1.0 work not been in separate plugins it would have been easier
to simply add some extra clauses to Broker::createObject() and
Broker::deleteObject().
A counter example is the federation code which is much more tightly
coupled to various points in the broker codebase. Had that been
envisaged as a plugin I think some different design decisions would have
been forced.
I will stress again that the real issue is about compile- and runtime-
optionality and lower coupling, not dynamically loaded libraries per se.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
