CaptRespect's Blog - Java Stuff

Avoiding Overusing Java Interfaces

nospam@example.com (Jonathon Roberts) — Wed, 19 Sep 2007 19:07:21 -0700

Everyone knows that a good interface is a good thing for a Java program. Interfaces help keep your program flexible and loosely coupled while also enforcing a solid contract between your objects.

But like everything else, too many interfaces are too much of a good thing. Abusing interfaces makes your code hard to follow. There can be too much code hiding, it becomes a burden to have to remember which implementation of your interface is being used. You can get to an explosion of files due to each class having an interface defined. This is one mistake I've been making lately. It's time to define some guidelines:

1. Don't use "Impl" in the class name.

If you can't think of a good descriptive name for your interface, maybe you shouldn't be defining it. I've found that for each class I have named MyInterfaceImpl I only ever have one implementation and that it probably would never make sense to have another implementation. Later on, if you do create a new implementation, a good name will probably also reveal itself. Refactoring to use the new interface is pretty straight forward.

2. If your interfaces keep changing, maybe you're better off without it.

An interface that is constantly changing may indicate that it is too fine grained. Maybe you can change that interface to use more general terms, or maybe you want to ditch it completely till it reveilles itself later.

3. Keep the interfaces small.

Noone wants to mock your 50+ method interface. (Yes, I'm looking at you ResultSet) Your interface should fit on an index card. If it can't, ask if you really need it. Is it too fine grained? Can you generalize it or break it up?

Dispite all this, remember that interfaces are still your friend. If you can cleanly define one, by all means do it. Just don't over do it.

Java Package Naming Conventions

nospam@example.com (Jonathon Roberts) — Tue, 04 Sep 2007 21:05:13 -0700

Naming your packages in Java seems pretty straight forward, but by changing your naming conventions a little you can track your dependencies a lot better.

The usual standard for a package name seems to be url.application.module
So something like : com.captrespect.roxorapp.dao

But what happens when the same class can be used in different applications and is not application specific? How do you tell which classes are specific to your app and which are not?
It may be best to not violate the DRY (Don't repeat yourself) principal and go the trouble of packaging all my potential common classes into a common jar. A good programmer will eventually refactor the code down to this if need be. But this is not trivial work, you've got an app to finish, and you aren't even sure if the class is going to be used in other applications at all. (But want to leave the option open)

Say for example, com.captrespect.roxorapp.dao has two classes in it:

RoxorDAO.java
QueryExecuter.java

RoxorDAO will use the generic class QueryExecuter to run the queries. QueryExecuter has nothing to do with RoxorApp and is a candidate for one day being refactored into a common jar.

To be able tell this at a glance, change your package naming conventions a little. So you would have

com.captrespect.dao.QueryExecuter and
com.captrespect.roxorapp.dao.RoxorDAO

Just because the source of the QueryExecuter is in your application, doesn't mean that you should name it that way.
This has minimal impact on your application while making it easy move the QueryExecuter into a separate common jar all without having to rename the package and make edits to all your dao's later.

Of course there is always a downside, mainly with logging.
If you are using log4j, you won't be able to configure the logger for the whole app with just one line: com.captrepsect.roxorapp=DEBUG
This will come into play when you have more than one application deployed on the same server.
But I see this as a limitation with the logger, and the benefits outweigh the cost of a few extra lines in your log4j.properties file.

GET Parameters in JSF

nospam@example.com (Jonathon Roberts) — Tue, 07 Aug 2007 17:38:37 -0700

We recently started a new project at work. The web application was going to be started by linking from another page. The links were going to look a little something like this:

http://mysuperapp.com/appname?mygetparam=program1
http://mysuperapp.com/appname?mygetparam=program2
http://mysuperapp.com/appname?mygetparam=program3

A few weeks before I remembered reading about how hard is was to use GET parameters in a JSF application. So a red flag went up in my head, and I did a little research. A bunch of sites told me that is hard to get your components to send requests via GET parameters, but it turns out it's actually easy to bind GET parameters to your backing bean. (Just putting them in the url is cludgy)

All you have to do is use the param object in your el expression:

<managed-bean>
<managed-bean-name>myBean</managed-bean-name>
<managed-bean-class>com.mysuperapp.MyBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
<property-name>myPropery</property-name>
<value>#{param.mygetparam}</value>
</managed-property>
</managed-bean>

Now your request scope backing bean has the value from the url.

Easy.