On another note, java related, I continue to write interfaces for simple beans (structs or data bearers). I consider this a good thing and the only downside I know of is that you write more code. Still, I wonder, are there other downsides that I do not know about?
Another random thought, what is the nicest way to name your interfaces and implementation classes? Howard Lewis Ship of hivemind & tapestry fame usually writes:
and the implementation class as
Personally I prefer not to use the capital 'I' as a prefix. This reminds me of the horrible Hungarian notation. I usually write:
ServiceNameand the implementation class as
Preferrably the implementation is in another java package from the interface:
However, I suspect that perhaps I shoudl really leave the package naming as is and remove the suffix Impl from the implementation. It is a pain to have the interface and the implementation to have the same name but different packages but somehting tells me that it really is "the right thing" © to do.
Here we have maven, the incredible build system that does everything automagically out-of-the-box. So, I have some small hobby-projects, they have been around for several years now. Some classes even date back to JDK 1.0 believe it or not. When I decided to release them as open source I thought that I needed a better build-system than building the separate things by hand every time I wanted a new version.
I started out using Ant and that is probably something you all know and hate, but it works.
Then I looked with envy on the cool websites that this tool called maven built. This was back in the Maven 1 days. So I started using that and I got my really cool websites, they looked exactly like the big boys websites. But that was for each separate project, I have dependencies between my projects and I wanted 1 website that linked to all sub-projects. Enter the "Reactor" plug-in. It soon became apparent that the documentation was a mess if at all existing. The multi-project problem had largely been ignored by maven developers and was close to impossible to handle.
So, back to Ant, I spent some long train rides messing with XSLT and soon had Ant-builds that could build sub-projects, collect information and generate 1 web for all projects. Then I found Ivy to manage my dependencies.
Ivy kicks some serious ass. It is difficult to get into, has some wierd XML to configure and the documentation could be better. But still, the documentation exists and is mostly correct and easy to read. Ivy "just works".
Enter Maven 2, this is where I'm today. Converting my beautiful, fully refactored Ant+Ivy build system to maven 2. This new version of maven handles sub-projects with ease., I haven't gotten around to see what kind of web sites it builds for those but I have confidence that they will look nice. Maven has some really strong ideas about how your directory layout should be. Still, the layout is logical and consistent so I can live with it. The advantage of following the maven layout is that maven "just works".
That is, until I wanted to create a distribution of my swing applications. I want to distribute a ZIP-archive with the following layout:
So I looked at the assembly-plugin for maven 2. It has some more XML to configure what it is to do, there even is an XSD to help you with the XML.
The XSD has the wrong (I think) namespace. The documentation sucks, it links to the javadoc for the MavenArchiverConfig or some such class. The link is dead.
There is another mojo (maven plug-in) on codehaus that claims to build application dsitributions. But that generates startscripts. I do not need start-scripts. My application JAR is an executable and have a class path set in the manifest-thank you. Well, it has if I use the jar:jar plugin in maven. The assembly-plugin probably can do the same but the documentation is... well you get the idea.
So maven 2 lives by the 80-20 rule. It does 80 percent of the work, the rest simply can not be done unless you are one of the persons that wrote the damn thing or you spend more time looking at their source than it takes to write the Ant-scripts an configuring Ivy.
Maven does not zoom.
It's kind of a given that it's the implementation that should have the mangled name - it's not going to be seen outside itself and its factory anyway. The interface name otoh will be exposed to the rest of the system.ReplyDelete
Yes, I agree. But when implementing such a pattern, what is the best way to name the interface, the implementation and the factory?ReplyDelete
Foo, FooFactory for the interface and the factory (the interface will be used most so it gets the best name, and the factory is a factory so it can be called factory unless there's something else to name it by).ReplyDelete
The name of the implementations are not very important, but if there's only one then FooImplementation is a good choice. If you use abbreviations in names, then FooImpl is an alternative.