Object Oriented Programming

Everything is an Object!

Well, this is what we are told. However, its not quite the case. Objects are rather special things.

An Object has behaviour

An object does something. It might not be much - in fact its probably better if it isn't much, but it certainly does something.

An Object has clear purpose

An object does do something, but it generally doesn't do more than one thing. If you think really carefully about naming objects, something that does two things is extraordinarily hard to name. Generally, [Naming Things] is really super important, and if you can't name a class simply, then you probably don't know what it does. If you don't know what it does, it becomes very hard indeed to make it do whatever it is supposed to.

[Test Driven Development] can help decide what objects are supposed to do. It isn't a requirement, but can really help. Its a hard sell, because it forces a change in behaviour, and I'm not going to try here.

An Object is constructed ready for action

Once created, an object should be ready for action. What does this mean?

It means, don't do this:

Why not? Spring would certainly have you write "Objects" in this manner. Well, there are a number of problems here. First and foremost is that we have no idea whether or not we have properly constructed our InMemoryFooBar properly.

Using [Setters] doesn't allow us to indicate programatically that certain dependencies are required, so in the code example above, we would not know until runtime, probably, that out InMemoryFooBar, also needs a NormanLocator, if it takes a Wurzel. (For an explanation, read up on MangelWurzels) We would most likely find out as a [NullPointerException] sometime during the program run.

Using [AfterPropertiesSet] or a similar mechanism to indicate that all required dependencies have been set on an object is dangerous, as it is something that can very easily be forgotten. The [AfterPropertiesSet] here is really taking the place of a constructor.

Look at how the code would have been written using a constructor:

If we had forgotten to provide the NormanLocator, then our IDE would have indicated such, and the code would have not compiled at all.

Using constructors gives immediate visibility of what things an object depends on (its invariants), and what things it does things with - the other objects that it provides services on or for.

In fact this is one of the most important lessons that Summer can teach.

An Object hides its insides.

This is where the ideas that Spring and Sun propose about object orientation are basically plain wrong. Encapsulation doesn't mean "lots of getters and setters". It means hiding stuff away.

Objects expose services to the outside world. They must not expose their state, otherwise other people can monkey around with it, in ways that the object either does not expect, or in ways that would violate the operational contract that the object gives the outside world.

Consider a trivial object, that adds two numbers together, and returns the result.

Its obvious that if the adder exposed some setter for the result, then somebody could monkey with its internals, making it return the wrong result.

Fairly stupid example, but the point is valid. If objects expose their state, then people will change it.

If not set then what?

If you construct an object with the right state, then interact with it using its own methods, then an object should never be in an inconsistent state.

In order to think about what this means when interacting with an object, it might be helpful to think of it as "passing a message to an object". Just asking it to do something with the arguments provided. If it likes the arguments, it will update its own internal state to reflect the action it was supposed to perform (the method), and the arguments it was given.

You will find that code with no setters has a significantly lower bug rate than code with setters. (Just changing the name doesn't count!)

Getters are bad too.

// TODO Explanation