conceptual problems with Java

First, as an illustration. Do you know what is the biggest problem with flowcharts? They are absolutely against any kind of functional or object-oriented development principles. Their impact on software development... it may have been more negative. If you think in the terms of flowcharts, your question is "what next" - which looks really ridiculous to any OOP- or FP-practicing developer.

Now Java.

Say, you have some kind of "base class" (e.g. Employee), and some kind of "subclass" (e.g. ArrogantEngineer). The subclass inherits some behavior from Employee, has some specific methods, and overrides some methods from its base class.

Fine. Does it help to communicate with other entities? We have several typical choices, "idioms":

• singleton - base class contains a bunch of static references to external worlds; they are magically instantiated, using either synchronized keyword, or "double check locking" idiom, or a fashionable, since Java 5, holder class (see Bob Lee's blog for details)


• factory - base class contains a static reference to a "factory" that produces references to other specific entities - this way we can decouple the other worlds from ours


• locator - like in CORBA or EJB, every time an ArrogantEngineer looks for a mouse, it has to start at "root context", ask for a MouseFactory location, etc. Maybe you have to start with MouseMinistry, and go down. Every time you need to move a mouse. Because the mouse you own may have expired.


• double dispatch - okay, you find your mouse, and make it move, but how does the mouse know if it is on the verge of its carpet? You ask it every time? This ic called micromanagement. You are not supposed to do that. The mouse should tell you. "Don't call us, we'll call you". The mouse does not know you are an ArrogantEngineer - but you do, and act accordingly.


• constructor - or setup, or configuration, whatever. Each Employee, on initialization, receives from an upper class representative all that they need for their future functioning. How does the "upper class" know that? That's their job; they are something like EmployeeMinistry, and know everything about everyone. Or they delegate to ArrogantEngineerMinistry which knows their subjects better.

What kind of mental model is this? Feodalism, I think. This is the world as represented in the minds of... yes, in the minds of Arrogant Engineers. I mean, Software Engineers.

Professional architects, I mean architects in building industry, see the world differently. First, nothing moves for them. Nobody owns nobody. Things consist of other things, and encapsulation happens on several levels. There is no communication between opposite walls or between the roof and the floor. If such a communication happens, it is called a leak, and should be eliminated.

What kind of a program would such an imaginary architect write?

It would be one enclosing class; everything that happens in the program, happens in the context of that class. Let's call it Enterprise. If there are some facilities that are directly available to everybody, so they are. We can introduce internal classes, like Department - these classes contain a lot of data which they may or may not publish. But they do not have to name the outer scope, the scope of Enterprise. And so on; employees access the data visible to them in Department scope.

I'm not saying it is an ideal model; it is just a slightly better model.

The problem with it in Java is that of course nobody wants to stuff all the code inside one huge file. And once you put it in another file, oops, you loose it: Java does not have mixins (yet), and so you cannot have an inner class, with a scope in an enclosing class, stored in a separate file. That's bummer.

P.S. (9/2011): Scala's cake pattern solve the problem more or less exactly this way. We have no traits in Java, so we are out of luck.