I agree with the semantics of package-by-feature. In Robert Martin's
"Agile Software Development: Principles, Patterns, and Practices"
book, he has a very big section on packaging and how it affects
coupling and reuse. I do see that many projects tend to ignore this
and package by layer (and I've been guilty of this, too).
My guess is that putting a class in a layer (or categorization) bucket
is much easier to do than putting it in a bucket by feature.
Certainly if we have to think about inheritance (e.g. I need to extend
a base Struts 2 Action class) then figuring out what package to put it
in starts to look like a similar problem ("Ah, put it in the place
with all the other things that extend Action!")
Another reason is likely to be the self-contained nature of many
projects -- if we're building a project and we aren't exporting some
portion of those classes to another team, we aren't forced to think
about API reuse or packaging. IDEs make it easy to search for classes
by name, so in that case it doesn't require much thought about where
they live.
Dan
On Jun 13, 7:15 am, Christian Beil <[email protected]> wrote:
> Hi all,
>
> John O'Hanley (http://www.javapractices.com) has an interesting
> article about harmful Java
> practices:http://www.javaworld.com/javaworld/jw-07-2008/jw-07-harmful-idioms.html
>
> What is your opinion on that? I'm especially interested in what you
> think about structuring packages? Do you package by layer (ie
> dao,service,controller,...) or do you package by feature?
>
> Cheers,
> Christian
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
