At first hand this may not seem like such a big deal. After all, we had methods, we had data structures - what is an object if not just a simple collection of methods, each of which takes a pointer to a data structure as a parameter, all gathered together somewhere nice and convenient.

Indeed, from a basic programming mechanics point of view that is all it is, at least until you get into polymorphism and the next principle "Interface" (and more on that in the next post).

However the concept of the Object and Object Based Programming introduced a whole new approach to programming which was, in my opinion, a far greater Paradigm Shift than the later much more lauded Object Oriented Programming.

Objects brought with them Object Design, and Object Design allowed designers to construct solutions on the basis of a model of the problem domain, rather than approaching the problem from the point of view of, well, a computer.

The programmer's job prior to the arrival of, let's call it, "Object Based Thinking", was along the lines of a well know University Textbook of the 80s called "Algorithms + Data Structures = Programs". Although a programmer would quite sensibly use names from the problem domain in the solution domain in order to make understanding of the code easier, the two domains were still very much separate. The solution solved the problem using its own artifacts - i.e. data structures and functions. Programming was procedural in the main because people generally think procedurally - i.e. in order to solve the problem we do this thing first, then the next, and so on. Keeping track of what was going on came down to Flow-Charts and Data-Flow Diagrams, and there was always a "main loop" somewhere, processing events and farming the work out.

Object Based Thinking turned that on its head completely. Now the solution domain consisted of interacting objects bouncing of each other like billiard balls on a table. No more main loops. No more data flows. Stack-tracing, that vital debugging technique of the procedural days, more or less lost its value as objects got smaller and better defined (cohesive and loosely-coupled) and as the number of billiard balls knocked and re-knocked around the table in response to one external input increased.

Indeed, in Object Design, you never think beyond what is using you and what you use - i.e. your immediate neighbours. Later on (next principle) you stopped even thinking of them (and them of you) beyond your interfaces. Reusability was just around the corner.

And with Object Design came the rather lovely realisation that this flexibility allowed you to build your solution as a close model of your problem. If the problem domain has a Customer asking for a Loan from a Broker, then the solution domain could have a Customer object call a Loan_Request function (now called method) from an object called a Broker. If the Broker has to check bank references on the customer before agreeing, again the software can have that Broker object call a Bank object's Check_References method passing in the Customer object. And so on.

And this makes software so much easier to understand that it is probably the most important development in software engineering that we have ever had.

But - there's something rather counter-intuitive to the engineer, who likes to think in terms of machines sorting out problems, which has definately caused a slowness in the acceptance of problem-domain modelling as a technique. Although it is clear that it cannot be taken to the n'th degree, the temptation to use algorithmic artifacts rather than problem artifacts in design is quite clearly strong (as I have witnessed in my career). However in my opinion, Problem-Domain-Objects are the linchpins on which the whole future of software development hangs - a future based on the steady increase of the ready-comprehensibility of the software that we write.

Richard

The Principles of Software Engineering: start previous