Object Orientation Pt 2

[yrwyddfa]

Pt 1

The human race has been fond of abstraction for years. For centuries, in fact. Abstraction is a concept or idea not specifically connected to one instance; a famous example is Newton’s model of gravity. Programmers have been abstracting for years since the birth of that ubiquitous thing called a function.

A very popular abstraction model is set theory; and its implication within the programming world has been immense. Set theory, and its power, is the mathematical idea behind Codd’s relational model, and because its basis is mathematical the ideas and rules are globally consistent.

The success of the relational model means that nearly every data storage technology, where the storage requirements are more than just cursory, uses it. Even for those technologies that don’t use it a driver that supports accessing it in a relational manner exists.

Object orientation is just another theory, and there have been plenty, but none quite like this.

In the real world – and I’m trying to avoid those awful ‘training’ examples which map OO onto the real world about as honestly as the moon is made of cheese – a significant software system is made up of many layers. This used to happen well before someone coined the term n-tier.

The bottom layer is the data storage. The choice is clear – you and I both know you are going to use a RDBMS; sure there are arguments about which implementation of the technology to use, but it’s underlying theory is going to based on DeMorgan’s and Codd’s rules and laws.

The next layer is going to be about how to get the data in and out of the data storage in an efficient manner. The SQL language is normally used, and it’s been highly successful.

Now we get to the interesting part. What comes next? If you are an OO fan then you are going to write a translation layer. You are going to convert one high level model into another. Why? The relational model has proved itself over many decades and is both a mathematical and commercial success. What’s wrong with implementing software against the relational model? Why do you want to convert your data into another high-level model? If you were honest you’d probably admit that you do it because either you were told it was the best way to do it, or simply read it on some website or in a book.

The rest of the layers are pretty much unimportant for this discussion, but the whole list (for an OO system) is something like this: RDBMS, data-access, Relational/Object Mapping, Business Logic, GUI. Of course, different people do things in slightly different ways, but nevertheless this is a realistic example of an n-tier system

Whilst writing this something occurred to me. I’m you’ve all seen the cartoons where the guy has a light bulb appear above his head? Well, that’s just happened to me.

N-tier systems split essential functionality into different logical, and sometimes (quite a lot actually) into different physical tiers. The layers are split by a necessity to divide essential operations, and ensure scalability.

Of all the technologies running around at the minute there is one that doesn’t subscribe to this philosophy: yup – you’ve guessed it, it’s OO. By it’s very definition, by the very mantra of encapsulation, the data and behaviour are mixed together in the same class. Behaviour simply doesn’t act on incoming data as the world of mathematical abstraction suggests it should do. It acts on data held locally. Data, and behaviour are consistently held together and are considered identical (which is what Turin’s big thing was – but at a very low level of abstraction, not at a business level)

Software, unlike the vast majority of scientific disciplines, requires some form of management of change. OO is completely oblivious at the most fundamental level to any concept of change. It should be self evident that mutual storage at high levels of abstraction of both the data, and behaviour is simply not a good idea.

I can hear the religious fervour of those who have already fallen for the seductive delights of the PhD driven software revolution (also known as scientific drivel)

Change, they say, is easy. You inherit from a different class, extend an interface, or hell damn it just override the function.

But can’t you see? This is such a bad idea. Such a terrible disgusting idea that it should never be allowed by law. There should be statutes written and discussed in the political institutions the world over to prevent people from doing this.

Inheritance is evil. There has been a massive increase in the number of technologies sold, and/or implemented that allow the decoupling of systems from each other. I spend a fair degree of time protecting my user’s data from hardware failure, or integration failure. The classic way of doing this is to use a temporary store such as queue, so that if the target hardware fails, when it recovers (or you buy new hardware) the software continues to process the contents of the queue and the data is safe.

When you rely on inheritance all the way down your class hierarchy you have a massively coupled system, which means it’s difficult, and perhaps impossible to design an external fault-tolerant system by default. I hope it’s no surprise to the reader that software does exist in the real world, and not just in the virtual world. I’m sure that die-hard fans will point to design pattern solutions, but they involve clever use of interfaces and avoid inheritance anyway.

Inheritance strongly implies a hierarchical structure to the software (both the data and the behaviour) Is this a good idea? Look at the extremely successful and mathematically robust relational model. The data structures are mostly acyclic graphs (of which a hierarchy is one.) How do you propose to write a data-mapping layer between an acyclic graph and a hierarchy? For those who don’t know a tree is a restricted form of acyclic graph. Once again we see that OO restricts what can naturally be modelled from the real world, and the relational model (I’m going to start using RM, now because I’m sick of typing ‘relational model’) allows you to model whatever it is that you need.

The more experienced OO programmers sometimes tell me that they try to avoid the use of inheritance as a rule, but happily admit, that it’s a feature of the language and in many cases it’s unavoidable, and there’s generally no other way of doing what it is they want to do. I mention ‘object-composition’ and all I get is a blank stare. If you’re into modern OO then I strongly suggest you learn what object-composition is and implement it where you can. Remember that Google is your friend (as long as you don’t allow them to set cookies) Object composition is far more flexible than inheritance, and its perhaps the lesser of the two evils.