I have a passion for talking to people, identifying problems, and writing software. When I'm doing my job correctly, software is easy to use, easy to understand, and easy to write... in that order. Michael is a DZone MVB and is not an employee of DZone and has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

All Java Architects: Read This

  • submit to reddit

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.

Published at DZone with permission of Michael Mainguy, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Dean Pehrsson-c... replied on Wed, 2012/04/25 - 2:39am

Pretty valid points, although I'd rather change 10 classes to add one field (assuming trivial changes) than change 10 places where developers did it their own way because there was no abstraction to use. Beware the row boat that ends up the size of the titanic when you're not looking.

Anthony Bennis replied on Wed, 2012/04/25 - 3:30am

Yup, I agree with the sentiment. Experience, In my opinion, is the only way you can learn this though. There seems to be a pattern in the learning curve.


  •  Junior developers start off almost completly relying on conrete classes, as the full OO concepts haven't sunk in yet. 
  • Then as they progress, read articles, are exposed to more code, they  start to realise the advantages of interfaces and frameworks, but over engineer solutions, add layers like you say, and don't know when to not use an interface. This can be a costly development stage for a project. 
  • But then, as they grow older and wiser, and end up maintaining complex frameworks and inheriting overly complicated code, they learn how to balance abstraction and implementation.
The only way I can think of to reduce the learning curve here, is to have less experienced developers work as much as possible with the strongest developers in a company so they can learn by example. Also, ensure there is plenty of prototyping so mistakes can be learnt there before working on production code.  


Owen Fellows replied on Wed, 2012/04/25 - 5:44am

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.

Earnest Dyke replied on Wed, 2012/04/25 - 7:19am

Agreed. I have seen way too many java developers who were produced in "programmer mills" who insist on having an interface for every class and value objects for every database entity. Application of a framework must be tailored to each system. Once size DOES NOT fit all.


Rob Connell replied on Thu, 2012/04/26 - 12:24am

I  totally agree with your point about Interfaces but it probably way too pragmatic to be accepted by some of the people reading this ....

KANAKA VARANASI replied on Fri, 2012/05/04 - 12:52pm

All points are valid. I have seen many architects or programmers beat around the bush instead of providing simple solution. One reason comes to my mind is job security.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.