All java archeditects read this

I have a couple of quick notes for any aspiring java architects. Please read them carefully and think about them.

Adding layers is BAD

In general, you don't need extra layers until you need them. At that point, add a new layer (but only in necessary places). Create "standard" layers just adds complexity, makes maintenance more expensive, and ultimately fosters copy/paste coding and discourages developers from thinking about what they're doing. An example of a good time to add a layer is when you need to hide complicated operations behind a facade because low level database transaction management is being done in the same place as the code that determines which screen should be displayed next. Too many developers heard "layers add flexibility/scaleability/whatever" and started adding layers to every situation that has an arbitrary division of responsibility... I've worked on systems where adding a table column to be displayed in a CRUD application required changing upwards of 10 different classes... this is a maintenance nightmare.

Interfaces have a special purpose, you don't need them for everything

Not every class needs an interface... They should be reserved for situations where an interface is useful and not just another unnecessary ceremony that developers will mindlessly follow "because that's the way we do it here". A good example of an interface would be something like "Nameable or Labelable". These are often contexts that systems need when rendering information ('cause toString() often won't cut it). The key point is that there will be many classes (at least more than one) that will implement the same interface in the system at the same time. If you try to hide an implementation behind an interface with the idea that the implementation might change in the future... Just use a concrete class and change the dag gone implementation when you need to change it. Don't force every update every developer makes for the next 6 years be TWICE as much effort...

Beware of one size fit's all solutions

Don't build the titanic when all you need is a rowboat. I've seen monster frameworks grow because of one tiny edge case. Instead of treating the single edge case as an outlier and walling of that portion of code from everything else, may architects make the mistake of trying to accomodate the edge case in EVERY part of the system. In addition to extra layers and extra interfaces, I've seen systems that generate javascript web service code, soap stubs, extra java classes to handle serialization, and any other number of overcomplicated plumbing... just because one or two calls in the system needed to be remote.

The short version is, don't overcomplicate your solutions and don't start adding code you don't need ahead of time. You'll be carrying that code on your back for every step you take and need to make sure you don't burn out hauling a bunch of unnecessary baggage.

Comments

Faisal Basra said…
I really like the post and 100% agree with your findings.

Recently, I have faced situation where developers adding frameworks, layers and interfaces making it all bloat & no sense. I left job because of these non sense approaches being practices by our seniors and we are forced to follow them.

I would like to copy this post to my blog as with credit to you.

Thanks
Owen Fellows said…
I think this all depends on what you are developing and how the code will be used going forward.

E.g. if you are developing an application just for yourself/your company and anyone that wants to update it will have access to the source code to change then I agree that you don't need to create as many layers, interfaces, etc.

However if you are developing an application which maybe extend by other user without access to source code then the creation of layers and interfaces is sensible. I say this having worked with such applications which don't give APIs to perform simple operations because layers haven't been created. This makes things like, creating a batch user creation process or webservices for user creation are far more difficult as APIs don't exist and you end up having to reverse engineer the logic.

I agree that the over use of layers can be a maintaince overhead but the correct use of layers and APIs actually reduces development effort as you simple reuse well designed APIs without having to refactor code when a logical layer exposes itself. Also although refactor is an easy solution for you, having the source code, for anyone that has extend the code it means painful analysis of what has changed and upgrading to use the new APIs you created because your original design didn't warrant their creation.

I think there is a happy medium between "just in time" architecture/development and "over engineered" architecture/development, the problem is different people have different opinions on where this line is drawn.
Javin said…
Great post, I found it on Dzone. regarding usage of interface they are key to design flexible System and Joshua Bloach rightly said on Effective Java that they are best for defining Type.

Javin
10 object oriented design principles for Java programmers

Popular posts from this blog

Push versus pull deployment models

the myth of asynchronous JDBC

Installing virtualbox guest additions on Centos 7 minimal image