Getters and Setters are evil

There had been a lot of ranting about this. I spare me the links, no I can’t resist…

There is much to be said about the verbosity, and I am big fan of the solution from C#. Syntax is part of the language and if you master the language you easily read over boiler-plate code and as we have brillants IDE, the boiler-plate code gets written automagically.

As the example from the comments,  a modern Java class like Enum offers methods like String name() and int ordinal() to access an immutable property. Not the absence of the “get”-prefix. The get/set convention came from JavaBeans that should enable application to discover properties via reflection. Most classes in a system are not JavaBeans, so why providing get/set on the attribute. In fact, this is harmful, if the calls are more than dumb properties. How to you document/enforce/verify that a certain call order of setter has to be obeyed?

Of course it is possible, but it gets soon very complicated. Back in the old days of Oracle Forms 3.0 we had nice forms where the user tabbed through, filling in the data in a specified order. The apps where sometimes quite complex and each field entered caused a trigger to be fired that changed the status of the app. This compare quite well with a non-trivial setter.

As we migrated later to Form 4.5, a GUI-client. The user had a mouse at disposition and the order could different - the application misbehaved or crashed in consequence (There was a feature to block these mouse-navigations to preserve the old restriction, thank you Oracle).

In the make-over I implemented a fulfledged state-machine to take care of the application state, the code maintaining the integrity topped the actual functional code in size an complexity (Lesson learned from this: RAD tools are great until you reach a certain level of sophistication - this is why I can still resist the RoR-hype).

As I had been facing a similar problem (it was Forms 6i by then), I took an extreme approach: I let the user work on a scratch-pad and took over the data as a whole. OK, it is getting boring now, but the key idea I still use today:

I treat the data from an interface as an entity, not as a sequence of events. I have one (or few) events and thus the receiving class’s interface gets smaller ( see rule 10) and the internal logic to maintain consistency gets smaller. When reading data from a user-interface I wrap the region into a ScreenReader that gets passed to the receiver.  The class can then extract the relevant data, complain about missing or wrong data and issue warnings about ignored data (useful here Bridges between different representations of input data and handler that collect exceptional data during the processing)

This replaces one of the most common uses of bean-style interfaces. The reasoning I hear most often is that such an interface is explict. Well it is, but the question must be allowed, why do we need this. Take a web-app for example: There are html-controls on one side and a RDBMS on the other side. Sandwiched between these string-based descriptive sources and drains we have our Java application. We have web frameworks that deal for a good part with mapping IDs of DOM-node to method-calls and an ORM that does the same to bridge to SQL.

Most of the data simply passes through - yiellding in endless set/get sequences* and in this haystack we have some critcal operations burried. Adding a new (stupid) field demands a refactoring on all layers, adding a intrivate field makes it even worse, because now you also have to think where in these chains of set/get it has to be inserted.

For the stupid case even the strongest evangelist for explicit bindings I know had enough of it and went along with a generic solution as outlined above. This had been infective.  We discovered that generic interfaces that are accessed by strongly typed Bridges preserve the safety of explicit bindings, but are a great deal easier to develop/maintain while improving reusablity (As a side-effect such a design forces you to separate clearly control and data flow; a proper MVC pops out without any effort - note that View in MVC needs not to be something visual!).

I got pretty explicit here… but before I forget about the *:

I’d been loudly thinking about something quite strong:

Rule X: Each block shall contain no more than one statement; curly braces are only needed for declarations, try, catch and finally.

Consider the use of behavioral patterns