A colleague asked me to help him learn java and object-oriented programming. He has solid background in
SQL. This is cool because I don’t need to explain things like the while loop or recursion. We can focus on the syntax first, then double-check Clean Code and we’re done, aren’t we?
Object Oriented Programming
This might be a fast lane for aspiring java developers. However, I still cannot define what does good Object Oriented code look like. There were so many contradictions during my education and career. I’m not sure if I should spare him this journey.
A sneak peak: I spared him the journey. I showed him Spring tutorials because they have good code and good architecture. Moreover, they provide an overview of all kind of machinery you you can use with java.
Let’s see the contradictions!
When we learn about object-oriented programming, then we learn about classes and inheritance. We all learned how we can use one class to draw shapes and another one to move them.
For greenhorns: call the
draw() method, then call the
erase() method, then move the cursor, then call again the
draw() method. Thus we can define the
move() method in the parent class,
Shape. The child classes, like
Rectangle can take care of the drawing details.
So we got the Template Method as an introductory example. Splendid. We might think, hey, inheritance is cool! Let’s build class hierarchies.
Later we learn that we should favor composition over inheritance. First it reads like, don’t write code with inheritance.
But we do. We use class hierarchies. So does Swing. We need to be able to handle this kind of code.
Later we learn what it really means: don’t use inheritance that often. For frameworks, interfaces or annotations are better.
As we grow professionally, we learn about the Dependency Inversion Principle. It says we should depend on abstractions. So we can write abstract classes or interfaces. Remember, abstract classes imply class hierarchies, and this is something we’d like to avoid. So we write interfaces and it helps us avoid dependencies on concrete implementations.
But we do depend on concrete implementations. It’s a matter of granularity. Wherever we want to
Later we learn not to write interfaces that often. Within a single module we probably don’t need them.
As time goes on, we learn about the DRY principle. For greenhorns: the DRY principle means don’t repeat yourself. Which reads like, don’t do code duplication.
But we do. We duplicate code because sometimes the duplication is only accidental. Later we learn not extract abstract classes that often.
We duplicate code because it’s way simpler this way, and we don’t want to violate the KISS principle.
The KISS principle stands for: Keep it Simple, Stupid. I.e. the code must be easy to understand. We must not write complicated code.
But we do. Other than our incompetence, we write complicated code because the underlying business logic is complicated.
There is no bottom line. We got several rules, principles and exceptions. All we can do is to gain some experience. Train our biological neural networks (brains) with lots of examples. Then we’ll be better judges of our code.
A real bottom line
Read code, that’s important.
Learn to deal with several kind of antipatterns. Learn why they emerge. Learn how they are useful.
As time goes on, you can unlearn everything.