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

[Michael S. <mi...@sc...>]

On Tuesday 22 February 2005 23:47, Martin Kersten wrote:
> >> 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! ;-)

I was pretty sure, but apparently wrong nonetheless, that you were 
referring to Robert C. Martin, aka Uncle Bob.

In particular, I thought you had some of these principles in mind
<http://www.objectmentor.com/resources/listArticles?key=topic&topic=Design%20Principles>


> 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.

I don't agree; at least I'm not convinced. For one thing, I've used 
parts of Spring without touching so much as a BeanFactory. To my mind, 
the Spring package structure is easy to follow. The level below 
org.springframework denotes some general concern that can be understood 
from the point of view of a developer using Spring. The packages below 
that are about more specific aspects or implementation.

As is, the package structure appears to be "taxonomically-inspired", it 
hierarchically groups related pieces. Whereas what you suggest is a 
"usage-inspired" grouping, where things that likely to be used together 
are put nearby.


> 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.

Let me suggest that the reason is not lack of focus, but a fundamentally 
different mindset regarding where things belong. I don't share your 
view and judging from Spring as it is, neither does the Spring team. In 
particular, I don't share the assumption that the deeper down the 
package hierarchy a class is located the less significant it is.


> 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.

Except for "Death March" I've read them, DDD is actually there on the 
list and the others just didn't make it.

> 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!
> :-(

I have "Data and Reality" by William Kent unread at arms length. It's 
approaching 30 years of age, but I've seen some recommendations 
recently. In general, though, I think software development should not 
try to mimick ontology. Epistemology may be more like it, thus modeling 
how we interact with the world instead of how it is in itself. 
Incidentally, we appear to exchange positions here. Where above I 
favored a roughly "ontological/taxonomical" approach, in this regard I 
prefer "epistemological/usage-based". But I fear that's just idle 
theory...


Michael

-- 
Michael Schuerig                   The Fifth Rider of the Apocalypse
mailto:mi...@sc...         is a programmer.
http://www.schuerig.de/michael/