What's object-oriented?

[Andrae Muys]

m.faassen at vet.uu.nl (Martijn Faassen) wrote in message news:<9h4rto$fmc$1 at newshost.accu.uu.nl>...
> zoodoo <zoodoo at infantry.com> wrote:
> > What's the concept/logic behind object-orientation? What is it suppose to
> > mean?
> 
> People noticed that good procedural programs often worked this way:
> 
>  * You have defined a bunch of data in a structure. In C, for instance
>    this is a struct definition. In many languages these are called
>    'records'.
> 
>  * You have a bunch of functions that operate on this data.   
> 
> The program would then be composed of modules, each defining a data
> structure (or bunch of related ones) and the functions operating on
> them (creating them, changing them, querying information in them).
> 
> Good procedural programs tend to look this way, because they're 
> more modular and easier to understand and modify. (this type of
> modelling becomes especially obvious when you're writing a simulation
> or a game, but it is useful in many places).
> 

Indeed.  In fact most good OOP books tend to use this as their
introduction to the concept of an Object/Class.  However while it is
historically correct --- in fact now I have learnt OOP my structured
code shows even stronger tendencies towards this approach --- I have
never found it a useful approach to actually understanding how to use
Objects.  (Note this is my personal experience, it may or may not
generalise)

Personally about half way through GoF, Fowler's book on Refactoring,
and Langr's book on Java Implementation Style I finally realised that
I could treat a well designed object as a State Machine.  Once I
realised that, most of the material in those three books became
'obvious'[1].

To summarise the approach I take.  The classical state machine has
inputs, state, next state logic, and outputs.  These map to methods,
members, implementaion, and attributes.

Now as soon as I accepted this analogy, I immediately started finding
exceptions, but it did mean that patterns such as Visitor, Strategy,
and State, started making much more sense.  Also, alot of the
exceptions seem to me to be OOP analogues of FP constructs (one of the
reasons why I like Python so much :).

All in all my engineering rather then CS background may explain why I
find this approach to understanding OOP useful.  I wouldn't be
surprised if the utility of this approach dosn't generalise, but I
thought I might share it as hopefully it will.

Andrae Muys
amuys at shortech.com.au

[1] cue old maths joke about the 10 blackboards of deriviations to
recognise the proof as obvious