Maven thoughts, then patterns thoughts

I'm still plodding away at Maven at work.  There was some discussion as to naming patterns, conventions, directory structure etc.  Most of these things weren't ground-breaking, just items that require agreement.  Without agreement, some benefits are lost.  The only point I wanted to see was that modules and Java packages corresponded.  Everyone in my group agreed with that idea, so I went to voice my concern with one of the main drivers behind the Maven efforts.  He said essentially the same thing, but pointed out an exception.  Imagine an interface is described in module I, with two concrete implementations in module A and module B.  If module I uses a factory, it must have special access to module A and module B.  Specifically, module A and module B should be non-public, package protected perhaps.  This leads to having the interface, factory and implementations in one Java package even though logically they three separate pieces.  I wasn't 100% comfortable with the example, but I couldn't identify any flaws in the reasoning.  Then I hit on why I didn't like it - I don't think I like factory classes.

I've used factory classes a few times in the recent past, but they aren't something I agree with as much.  They are hard to test and the classes that use factory are also hard to test.  I think I would prefer each of the modules be a separate Java package with a single public entry point in module A and module B.  The user would be able to determine which implementation to use, instead of putting all that logic in the factory class.  However, either implementation would work and are equally correct.  It also illustrated the point that the name conventions and layouts are guidelines, not rules.  The exceptions occur frequently enough that slavish adherence to particular rules will cause more problems than necessary.  Rather the rules are there to help remind people to really consider why they are using complex constructs.

This brings me to some thoughts on patterns.  The Abstract Factory pattern was mentioned above and my desire to avoid using it comes from a certain unease with ideas of software patterns.  I've previously had discussions with a co-worker who expressed the idea that there is something wrong with patterns, but he couldn't put his finger on it.  I suggested that it was because the patterns don't solve all problems (otherwise software development could have been fully automated by now) and the pattern requires adjustment all the time.  It seems like the problems are fit to the patterns, rather than using patterns to solve problems.  I think that patterns have been used by those that want to turn software development into more of an engineering discipline with common issues that simply need to be recognized and well-known (well-described?) solutions applied.  I agreed that these were my ideas on the topic, but didn't do the unease any justice.  My co-worker has been reading Christopher Alexander's book on pattern language, as Alexander is the source of the ideas adapted to software development.

I suppose the real issues come from those who apply the software design patterns too easily, without first considering the problem.  As time has gone on, I've been adding criteria and considerations to things I need to design.  Things like ease of understanding the result, simplicity of implementation, testability, current requirements.    Also, with the various patterns I've been involved in, they've been customized and adjusted in ways that suggest one of two things (or both): 1) pattern didn't fit and the problem is being adjusted to suit the pattern and 2) so many adjustments are made so that the pattern is only partially there.

Anyway, this is not a well-reasoned argument - it's barely written down at all!  Hopefully I will be able to devote some more thought and then more time to describing some of these things more coherently.  Not tonight though.