Must Read Article: All Java Architects Read This

By | August 22, 2012
Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

This article was originally posted in DZone by Michael Mainguy. It’s short, sweet and to the point.

All Java Architects: 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.

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

Subscribe to get the latest updates

  • You sound like a developer…. Something that I have learned from over 25 years designing and developing applications is USERS DO NOT KNOW WHAT THEY NEED, THEY ONLY KNOW WHAT THEY WANT. Here it is when interfaces and a robust architectural design come handy. I agree that you do not have to add layers just because you read somewhere that it is COOL and you want to look sabby and snobby; but a solid architectural design with GOOD PRACTICES on it will most likely save you tons of headaches.

    • I have to agree with you, Carlos. You make a solid point.

  • Think you’re a bit too harsh in your discussion of interfaces. There are many cases where interfaces are very useful – for extensibility (I need that type but not your specific implementation), for unit testing (I can stub out an interface and use the stub in my test), and to make dependency injection more maintainable.

    I’ve found that service and data access classes usually should implement interfaces. Anything can be overdone, but the projects I see suffer from too few interfaces not too many.