In this installment we are going to dig further into Idea #3 from Building the Enterprise Hammer:

The transition from EJBs to POJOs is only a halfway point. We now need to leave Plain Old Static languages (POSs) behind.

Developers have already rejected “special hammers” (past versions of EJB), in favor of plain old hammers. This is a great step towards more flexible applications. However, they still typically mount their hammers in some kind of frame (e.g. Spring). What happens when this frame is not perfectly adapted for the task at hand, or when the task at hand changes?

Let’s say, for example, that we wanted to repurpose our Enterprise Hammer as an Enterprise Window Washer, by installing different attachments. We believe that this should work because:

• Windows are regularly spaced on the side of the building.
• Window spacing has a known relationship to the spacing of nails hammered by the Enterprise Hammer.

This is an example of refactoring to generality: finding similarities so that you can cheaply provide a new function (washing windows) through the same mechanism that provided the original function (driving nails).

Java makes this kind of generalization difficult. Java encourages up-front rigor about the type of an object. If you decide later than the “Hammer” type can be generalized to “Widget”, you may have to touch hundreds or thousands of lines of code to enact that change. Duck-typed languages, such as Ruby and Python, encourage less assumptions. And, the assumptions are easier to change later. This is one place where the 10x hype is real.. Duck-typed languages can be an order of magnitude more productive, in both developer time and lines of code, when designing for (or refactoring to) generality.

There’s another issue here, as well. Our Enterprise Window Washer may require changes to the frame itself, since windows are spaced differently than nails, and washing requires a different motion than hammering. But, we didn’t build the frame. What are our options? Many languages provide a simple solution through open classes. With open classes, our own application code can make spot modifications to the frame to suit our specific needs. Conversely, Java discourages this flexibility in two ways:

• deliberately, by closing classes
• inadvertently, through its complex deployment model

As a result, Java developers may learn to not even see opportunities for reuse. Elegant solutions are not only not chosen, they are not even considered.

But More Flexible Languages are Dangerous!

Yes. There are many good reasons that Java became dominant, instead of e.g. Smalltalk. Understand those reasons, and you’ll also know why it’s time for a change. Stay tuned for the next installment.