2010-10-25

Inheritance is evil.

A common mistake in Java code is the over-use of inheritance.  You should always favor composition over inheritance.  If you do extend a class, and the class you are extending is not an abstract class that has a damn good reason for existing, you had better have a good excuse ready.

On second thoughts, spare me the excuse and hand over your lunch-money.

If you extend concrete classes often there is something wrong with the way you program and you urgently need to learn how structure programs.  Seriously.  These are beginner's mistakes and if you think of yourself as something more than a beginner then this is reason for grave concern.

Of course with composition comes dependency injection and with dependency injection the temptation to involve something to do the injection for you.  In a word: don't.  If you belong to the subspecies of programmers who thinks it is better to wire up your programs in XML rather than code, then you are a moron.

Take it one step at a time.  Start by overcoming your fear of writing concrete classes that do one thing without prematurely being split into a bunch of classes.  Yes, there is surely a more general way to do anything you can think of, but you are not going to need it and anyway: you are not that smart.  If more than half your classes are generic fluff then you are not being productive;  you are just masturbating.

When you do need to break things up and the design you come up with calls for extension of concrete, non-abstract classes:  find a hammer and hit your big toe.  Hard.  If you do not have the stomach to do it properly I will be more than happy to do it for you.  This is good for you.  This motivates you to become a better programmer.  Treasure your remaining big toe.


I have just spent the better part of my evening trying to understand a piece of code that makes use of pointless "onion programming" -- where the behavior of a class has to be divined by peeling away successive layers of inheritance and inspecting each layer to slowly figure out what is going on.

This is fucking tedious.

Especially when no thought has been put into naming and the organization of packages is completely willy-nilly.  What you call things is important.  It tells other people what to expect.  If unsure: ask someone who knows a thing or two about API design.  If you spend half of your time coming up with good names for types and the rest of your time programming, well, then at the very least you will spend half your time not writing more shit code.

If you want one piece of advice it is this:  Chances are you are not very clever.  Also, your code does not really interest me.  I look at it because it causes friction or doesn't work.  (This is due to the you not being very clever part).   Not because I am admiring your work.  I am only interested in what it can do for me.  The less I have to read and the more I can assume, the happier I am going to be with your code.  The more involved I have to get the angrier I will be with you.  Please write your code in a manner that lets me get on with my life, and I'll stay out of yours.

No comments:

Post a Comment