Home‎ > ‎

The superior use of OOP

Object Oriented Programming is a language paradigm open to several different philosophies of use, and some of these philosophies will get you into trouble. But the problems with OOP are not fundamental but anthropological, as individual programmers experiment with production code during their odyssey to learn its strengths and weaknesses. The most valid criticism of OOP as a paradigm is its shallow learning curve, which means it takes a long time between when a programmer thinks they "get it", and when they actually do. Declarative and functional programming languages have a steeper learning curve, so while they are harder to initially comprehend, the programmer reaches maturity in a shorter time.

Someone sits a Pascal programmer down and says, "OOP is Records with Procedures in them", or sits a C programmer down and says "OOP is structs with functions in them", and a few months of development later you get a mess. So the next time the teacher sits down with a procedural programmer they say "OOP encapsulates data in order to hide its implementation". A few months later you get a zoo of digital animals with no taxonomy. So next you explain inheritance, and you get "Car inherits from ParkingLot". The next stage is an explosion of "Manager" classes, but now the programmer is beginning to understand; the "Manager" classes may be hoarding functions, but those functions are now starting to manipulate smaller, lighter entity objects.
this.GetData();
this.ProcessData();
this.FileName = "myfile.dat";
this.SaveData();
The next hurdle is respect for the class's fields and properties. You'll see classes that pass parameters to its own method by manipulating some fields just before invoking it. Imagine building a bookcase by cutting gouges in the wall that are the length and thickness of your shelves, slotting the shelves into the gouges, and then nailing the sides of the bookcase onto the suspended shelves.
IO.File.WriteAllBytes("myfile.dat", Banking.Amortize(this.loan).ToBytes());
Slowly a habit emerges, and the programmer stops putting complex functions into data types and creates fewer types. The "Manager" classes stop maintaining their own state and begin to turn into static classes that don't do more than transform information from one state to another. ToBytes(), ToStream() and ToWhatever() become the methods most likely to be found in an entity class. Inheritance fades in prominence, inversely proportional to the rise in interface use. Until the OOP features that used to be used like flour and sugar are now used like spice and salt, and programs become less and less like an object menagerie and more like a procedural program with some OOP-ishly embellished data structures.

The programmer is now using OOP not to hide the implementation of a class, but to make the syntax of other code easier to comprehend. The classes can be re-used not because they can be extended by inheritance, but because most don't have any business logic in them at all.

Instead of creating the class Ellipse and then struggling over whether to inherit Circle and add another foci, or have Circle inherit Ellipse and hide the other foci, the programmer just makes two separate classes that inherit Shape, and the only reason he didn't use an interface is because Shape's two lonely properties hold the X and Y. Instead of overriding a Draw() method and passing it a "graphics context" to draw on, the programmer just implements IDrawable, which has one method called ToPath(). His boss is pleased when he discovers ToPath() replaced several overloads of both Draw() and Save().

Reuse of code stops being a religion, and the programmer does Repeat Himself from time to time, but you can tell it's because he's now a better judge of when it's not worth the hassle to avoid.

Later the programmer's favorite language gets another update, just like it had two decades ago. But this time the new paradigm is functional or declarative programming. Again, the programmer goes through an experimental phase, comprehending the new features and then taking a while to "get it out of his system". But the OOP programs he was maintaining transition easily to the new way, mainly because they were no longer over-invested in OOP to begin with.

Also see:

Comments