Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Martin K. <Mar...@St...>]

>> Also I would love to see Spring being applied to
>> the 'Interface belongs to the client' design principle. :-)
>
> A faithful of the church of (Uncle) Bob, or so it seems ;-)

Who is Bob? :-) I am with Fowler and Kent! ;-)

> If I understand you correctly, you bemoan that currently abstractions,
> i.e. interfaces, and their implementations often live in the same
> package. This presumably results in these packages being off the
> mainline, meaning they are neither abstract and stable, nor concrete
> and instable.
>
> Your suggested solution is to move the abstractions to the packages
> where they are actually used. Thereby rendering their originating
> packages more concrete. Now, what would the outcome be? As most of the
> abstractions are used from multiple client packages, they can't be
> moved to any single one of them. Instead, new "abstract" packages would
> have to be created for them.

Nope! Look at the ApplicationContext within the package *.context.

Applying the interface belongs to the client is like this.
The ApplicationContext for me is the core component of the
springframework the way I used to use it. Define a context and
off you go. So where does the ApplicationContext  interface belongs to?
Well it is about the org.springframework package. The springframework
is the client being in need of the ApplicationContext to deliver use for the
people.

When defining a library the library root module becomes the client.
It's that simple. In our example moving ApplicationContext to
org.springframework where it belongs to, you state to the user of the
framework that everything of the sub packages is somewhat related to
this interface. So the whole context-subpackage becomes a package
only existing to implement the features the application context promises
the user of the framework.

That's it. And when you do this consistently among the whole
framework you wouldn't see this explosion of sub.packages.

AOP is a real difficult modul. It is more like a utility modul I guess.
It provides help everywhere. Thats the nature of aspect oriented
programming, I guess.

Also the seperation of subprojects becomes natural. For example
if you try to pull out some client interfaces of the web modul and
justify the existence within the org.springframework package,
you simply fail. It's somewhat special. Thats the point to tip your
toe and split the project into main and sub-project.

> Yes, this change would probably improve the scores on some design
> metric. Still, I'm somewhat sceptical if improvements of, say,
> learnability or maintainability would ensue. Also, as a matter of fact,
> Spring packages are not released individually, thus it is not very
> important to keep their interdependencies low. -- Your turn.

It is about focus of the people working within sub-projects. I often
see usefull code being not pushed up the package hierarchie just
because the lack of focus. It doesn't look like web push it up.
Somewhere would be the right place. But this doesn't happen often
when you deal with string manipulation etc. I dont know how it
is in terms of Spring since it is only providing some kind of coupling
and not implementation. Maybe the duplication in functionality (not code!)
is not that bad.

Martin (Kersten)

PS: Nice reading section by the way. I would like to add that
"Code Complete,2nd Edition"(++), "Mythical Man-Month"(+++),
"Domain-Driven-Design" (+++!), "Death March" (++),
"Software Project Survival Guide" (++) are also some great reads.

PSS: Saidly but "Analyse Pattern" was the first and last book
that Martin Fowler wrote about world analysation. I got a great
lesson lately completly focused about analysation pattern and
another one called requirement enginiering. That was mind
altering, I can tell you! But there is no standard book about this! :-(

> Michael Schuerig                           The more it stays the same,
> mailto:mi...@sc...                        The less it changes!
> http://www.schuerig.de/michael/      --Spinal Tap, The Majesty of Rock
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer