Object Oriented Hell

Did object oriented programming manage to keep its promise of better code structure?

I stumbled upon this quora answer a couple of days ago and I can’t but agree more with the points made:

Object Oriented Programming

OO didn’t lead to better code

It’s just an abstraction like others (i.e. functional programming) to be honest. Not a magic wand that will make programs write themselves.

Java and to a lesser extent C++ were used improperly leading to increased complexity instead of encapsulating it when really necessary

Avoid at all costs inheritance. The only place I’ve seen inheritance work properly is with UI frameworks. So unless you are rewriting Swing or the Flash Virtual Machine don’t do it.

An excuse for ignorance

Many Java developers end up knowing nothing about how a computer actually works. They are just trained to write classes but can’t tell you how an http call works… what is a host header… how cookies work etc

When asked to help with recruiting web developers the first question I ask is where cookies are stored by default in the technology most familiar with the candidate: 99% of times their first answer is wrong. Java devs score even worse than PHP ones.

Classes everywhere

Not sure why but I had seen simple Java webapps with over 1000 classes and 100k instances loaded at runtime. It’s a miracle that the JVM can cope with that…

The usual pattern is as follows:

A well written web app (no matter what technology) should have only controllers, services and a DB abstraction layer. nothing else.

If-then-else abuse

I’ve seen this over and over

if(specialCondition) {
} else {

which over time becomes

if(specialConditionNew) {
} else if(specialCondition) {
} else {

Don’t use if-then-else statements to branch based on your dataset. It most likely a symptom of bad programming. Use polymorphism instead and keep your execution flow one (no branches).

Unit testing everything

Testing or automated testing is a growing necessity. Unit testing just does that: tests a unit (or class). When you test hundreds of useless classes with no business logic, what do you achieve? Nothing but you end up having way too many tests to write and maintain for no reason.

Prefer functional testing and use unit testing only when there is some business logic to test (i.e. input sanitization, parsing, regex manipulation)

Small is better

It’s much better to have 1 developer working on many projects that many developers on one project

Build many small programs that talk to each other (micro services) and do one thing and one thing only

This is how small software companies operate. No surprise they usually make better software.

This approach is more difficult to KPI as it clashes with sw engineer commoditization and outsourcing but also with time/power tracking.

Big means more overhead

A big software:


comments powered by Disqus

Subscribe to my newsletter