I don't know why I'm up so early on a Saturday, but I am. *yawn*. So I've been writing a paper reviewing other texts, to explain why Object Thinking is the natural way to think.
I am doing this because I do not want to lose an internet argument. I know. I've already lost. Both side have. That's how internet arguments work.
The argument is at Programmers, particularly my answer to the question "is OOP hard because it is not natural?" SK-Logic is zealously anti OO, and I am equally zealously pro OO.
Then the other day I was discussing what I'm writing with Pierre 303, in the Programmers' chat room, and he suggested that I make it into several 'blog articles, because then it would be easier to digest. I agree, so that's what I'm doing. I still don't know why I'm up so early, but at least I'm doing something.
Introduction
Object Thinking; it's been around for decades as a paradigm for software design, but what is it? When presented with a problem, someone using
object thinking will start to decompose the problem into discrete
sections that can interact with each other. You could, for example, be forced to change the tyre on your car. A simple task, certainly, but to do it you must understand the tools and relevant components of your car, and how they need to work together to achieve your goal.
It might take several attempts to achieve a fine
grained enough understanding to effectively solve the problem. Your
first pass at the above example might leave you with the idea to take
the wheel off your car. A second thinking might make you realise that
you need to lift the car off the floor to do that, and so on.
One thing that can give you a head start in
solving a problem using object thinking is background knowledge.
Knowing about your problem domain, what the objects in it are capable
of, makes it easier to plan how to use them. Not knowing enough can
cause issues, however, if assumptions are made based on incomplete
knowledge.
For example: You are asked to stick a poster to
the wall, without leaving holes in the wall. You are given a hamster,
newspaper and some Blu Tack®, along with the poster. If you don't
know what Blu Tack® is for then your understanding of the problem
domain is incomplete and you could end up using the hamster to chew
up newspaper into balls, and use those to stick the poster to the
wall.
It is also important to note that not everything
present in your problem domain will necessarily be used to solve the
problem. So, in the previous example, you might not use the newspaper
or hamster at all (or, of course, you might find the hamster solution
better, as it reuses the newspaper, which is more ecological).
So how does this apply to software design?
Software is just “algorithms and data structures”, right? Well,
at the end maybe, but you've still got to design it. Software is the
output of people's attempt to solve a problem. Solving a problem with
object thinking is the natural way, as this series of posts hopes to
demonstrate, because it uses people's natural problem solving
techniques.
Object thinking is a core tenet of Object Oriented
Design (OOD), a well known software design paradigm. The inventors of
OOD set out to fix what they saw are the main problem with software
design – software design was taught to make people think like
computers, so that they could write software for computers.
A book that extensively covers the meaning and
practical aspects of object thinking is Object Thinking by David West
(2004, Microsoft Press). In it he likens the way that traditional
programmers use OOD to writing lots of small COBOL
programmes [1]. Objects in this sense have been turned into data
structures with algorithms wrapped around them. While modularising
code is better than having one large function, it only makes
designing software a little easier. It still focuses the attention of
the design on how a computer works and not how the problem should be solved.
So what makes reasoning about large systems
easier? Focusing on the problem space and decomposing it into several
smaller problems helps. But what is easier to think about? Is it
easier to think how those problems translate into code? Perhaps in
the short term, but you will end up solving the same problems over
and over again, and your code will probably be inflexible.
Would it be better to think about software design
the same way you think about solid world problems? That way you can
use your innate problem solving skills to frame and express your
design.
It turns out that the way people reason about real
world problems is to break them down into smaller parts, using their
background understanding of the problem space, take the parts of the
problem space and treat them as objects that can do things and have
things done to them, and find way for the objects to interact. [2]
This works well because people like to
anthropomorphise objects, so that they can imagine the object doing
things under its own agency, even if in the end it's a person causing
the action.[3]
How can you be sure this is how you think, and is
therefore the more sensible way to approach software design? Well it
turns out that there is an oft ignored backwater science known as
Cognitive Psychology, and scientists in this field have been studying
people for decades, to find out how they work.
Future posts in this series will review certain cognitive psychology and neuropsychology texts and expand on how this applies to object thinking. The end goal is to demonstrate that object thinking is innate and therefore the best strategy for designing software.
Next post in the series: Object Thinking - Objects: a neurological basis
Next post in the series: Object Thinking - Objects: a neurological basis
References
[1] Object Thinking, D. West (2004, Microsoft Press) p9
[2] Problem Solving from an Evolutionary Perspective visited 9th July 2011
[3] Object Thinking, D. West (2004, Microsoft Press) p101
Blu-Tack is a registered trademark of Bostik. I am not affiliated with Bostik.
