Object-oriented programming objects aren’t objects
The previous post provides an intuitively clear motivation for object-oriented programming. The difficulty is that very little object-oriented programming actually conforms to the pre-theoretical explanation. To explain this, it will be useful to take a look at a very simple class from an object-oriented language, Java.
class Bicycle { int cadence = 0; int speed = 0; int gear = 1; void changeCadence(int newValue) { cadence = newValue; } void changeGear(int newValue) { gear = newValue; } void speedUp(int increment) { speed = speed + increment; } void applyBrakes(int decrement) { speed = speed - decrement; } void printStates() { System.out.println("cadence:" + cadence + " speed:" + speed + " gear:" + gear); } }
The above is an example of a bicycle class taken from the Java Tutorials, a series of tutorials for learning the Java language put out by Oracle, who have held the rights to the language since their acquisition of Sun Microsystems, the language’s creator, in 2010. The class’ fields are cadence, speed, and gear. In this case, the fields do seem to fit into a (non-exhaustive) list of properties that a bicycle can have.
The class’ methods, however, don’t reflect the pre-theoretical intuition at all. Rather than representing behaviors of the object itself, these methods represent ways that the fields of an object can themselves be changed or acted on: the changeCadence method, for instance, doesn’t accurately reflect an action performed by the bike itself, but rather one that the bike’s rider could perform to it. Worse, the printStates method, which prints the bicycle’s cadence, speed, and gear to a terminal, doesn’t reflect anything that someone could do with an actual bicycle. Instead, it represents a task that a program or user can perform on an instance of the bicycle class understood precisely as a digital object in digital space.
Stay tuned for more later.