software design question

[John Roth]

"Uwe Mayer" <merkosh at hadiko.de> wrote in message
news:c057uq$4ph$1 at news.rz.uni-karlsruhe.de...
> Josiah Carlson wrote:
> >  From the sounds of your posts, you want your software to be "modular",
> > in that you want have one file for each of the different components, but
> > you don't want to spend the time to pass down all the proper references.
> >   As a result, you want to have a single global namespace for all of
> > your modules, so that you don't have to pass anything down.
>
> Almost. I want to write software from components. I want a simple, yet
clear
> and effective interface for the components to communicate with eachother.
> The components will be dynamically loaded. If available they have to fit
> like a piece in a puzzle, if ther're unavailable all related functionality
> will be unavailable - *not* raise exceptions or cause program abortion,
> etc.
>
> I simply cannot pass all components to all others, because I don't yet
know
> which components there might be.
>
> Having a single global name space is poor software design. It makes you
not
> having to think about "inter module communication", because there is none
> to take care of, because you can call virtually everything from
everywhere.
>
> > There is another kludge:
> [...]
> > I would suggest you just put everything into a single file.  500 lines
> > is not that large.  Heck, a few thousand isn't even that bad, as long as
> > you pay attention to what you are doing and use an editor with a
> > browsable source tree/class heirarchy, and comment liberally.
>
> Wow! You can't seriously suggest this as a software design recommendation!
>
> Importing the complete namespace from one module into another is exactly
> what will cause you fourty hours of debugging code afterwards.
>
> Do you think there is a reason why in Java every class got to be put into
> one source file - or is this just a bad language restriction?
> Don't get me wrong, I'm not critisizing Python here.
>
> Searching the litherature I found the following on how to model
interaction
> between modules:
>
> - relations between modules should be hierachial, i.e. non-cyclic
>
> problem with circular dependencies: "nothing works until everything works"
>
> benefits of non circular design:
> 1. development and testing step by step is possible,
> 2. you can build subsets for
>    - use in other systems
>    - own re-use
>
> *sandwiching*:
>
> cyclic dependencies may be resolved by refining the modular structure:
>
> A <==> B
>
> Suggestion 1:
>
> A1 ==> B ==> A2
> A1 ========> A2
>
> Suggestion 2:
>
> A2 ==> B2 ==> A1 ==> B1
> A2 =========> A1     B1
>        B2 =========> B1

As I suggested in another post, this doesn't always work in practice.
Another term for hierarchical design is layered architecture. The
rule in a layered architecture is "call down, notify up." It's the higher
layer's responsibility to call down to install callbacks so that the
lower layer can notify up at run time.

What makes this work is that the notifier on the lower layer
can't depend on there being any callbacks installed. In other
words, it should be able to do whatever it does if nobody
is listening.

John Roth
>
> Ciao
> Uwe