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! ;-)
>
> I was pretty sure, but apparently wrong nonetheless, that you were
> referring to Robert C. Martin, aka Uncle Bob.

Well, well, Mr Martin is for sure a person, I know about. But I never
heared of Uncle Bob. But Martin's books are great stuff :-).

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

Ok I read his works, so I know them. But
'Dont ask just tell' is another strong principle he don't refer to. I dont
know how this matches his collection of favorite principles.

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

Thats how it is said to be thought of. But think about it, why does the
*.web modul doesn't contain any type/classes? Wouldn't you
expecting something going on here?

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

Well you are user centric anyways. Dont implement something that
noone uses. So there is a usecase for everything within the spring 
framework.
But use cases are about functionality and the main functionality should be
expressed by the main modul/package.

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

It's about specialisation. The deeper the module lays in the hierarchy
the more special is the use case scenario.

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

'Death March' is a nice one. Alexander's pattern book should
be read also ;-). 'Writing effective Usecases' is also a good one but
its layout is flawed. But I guess this one you also read.

Any recommondations beside the books you state in your book list
(read most of them).

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

I guess this book was a base foundation of my lessons. Well I only
go with the use-case centric approach. Everything is based
on the usage experience of the user. Do the simpliest thing to
satisfy the user. Supporting modules have to satisfy the needs
of the parent modul. But how does the parent modul forumlate
the requirements about the implementation? The parent provides
the interfaces the sub-modul has to satisfy. That's all.
Parent (Client) defines the needs by providing interfaces. That's
why interfaces should belong to the client. That's why parent
moduls are the client of sub-modules. And that's why I argue that
way.


Cheers,

Martin (Kersten)
>
>
> Michael
>
> -- 
> Michael Schuerig                   The Fifth Rider of the Apocalypse
> mailto:mi...@sc...         is a programmer.
> http://www.schuerig.de/michael/
>
>
> -------------------------------------------------------
> 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