[Tutor] designing POOP

[Alan Gauld]

"Michael Langford" <mlangford.cs03 at gtalumni.org> wrote

> I'm firmly with Kent here: OO programming is not about simulation.

Wooah!
I'm partly on board here and do agree the noun/verb thing is
a gross simplification. But it does work and is how probably
the majority of OOP programmers started out - in the 80's
and 90's at least. Certainly when I started on OOP around 1984
it was the de-facto introduction. And it is a still an effective
way to identify objects if you aren't sure where to start.

But it is not a good way to model software, with that I
agree. But OOP is still about suimulation. A lot of OOP
code - especially on very large scale projects is as close
a simulation as possible to the real world problem as
you can get. If you are going to work on 5-10 million lines
of code you had better organise it according to some
tangible model you can understand or you will have
problems. Performance and efficiency come a long way
behind comprehensibility at that scale. But on more
"normal" projects, say 100K-1 million lines then other
factors come to the fore, and flexibility of design is one
big area where OOP techniques can help.

<RANT>
Unfortunately there seeems to be a lobby at work in OO
these days (indeed in software engineering generally) that
has forgotten about large scale stuff and treats the entire
subject as if it were exclusively about small scale projects.
This is unfortunate because software engineering was
"invented" to tackle the large scale problems not the
small, and this view also fails to recognise the very different
approaches needed to cover both bases. Here in the
Python community we rarely need to think big, I don't
know of any really large projects being done in Python.
But it is important to remember that topics like OOP
cover all areas.
</RANT>

> are not modeling real world items. You are making code easier to
> maintain and making parts of code that have to do with one another 
> be
> near one another.

That's true of any design technique regardless of whether
it is OOP or procedural or even of it's not software at all.
However it's not somerthing that will help a beginner see
objects in their code, especially since the resultant
objects are often of the highly abstract or large grained
variety.

> If you spend all your time trying to make your objects into real 
> world
> things you're actually doing simulation, not programming. As a 
> person
> who's actually done simulation, I'll state that 's not really a 
> great
> way to structure code. You spend a lot of time arguing about highly
> abstract responsibilities of each object in your system, as well as
> how much it will actually model the real world. Neither one is
> especially helpful,

This bit I do agree with. Model the real world to get a feel for
the problem at hand, model the real world as an aid to identifying
potential objects, model the real world while it helps solve the
problem. But don't be a slave to it, you are writing a program to
solve a problem not to model the world. Never forget which is
the tool and which the result.

But OTOH most of the programs I build or design are simulations,
whether of a call centre, a manufacturing plant, a banking system
or a local council, an airport traffic control system or a telephone
switch - and the software invariably reflects that structure.
It does not however model every feature of a PBX, lathe, teller etc
It reflects the attributes of those objects that relate to the 
problem.

> programing. The Why of OO programming today is: To make code more
> maintainable/usable and to group and to use data in such a way the
> human mind can easily grasp all the abstract data types that a 
> program
> operates on.

And the latter point is one area where modelling based on real
world entities can be a big plus. But based on them, not slavishly
reproducing them.

> OO programing came from simulation people. They used a language
> (Simula) to do simulation. It allowed each object to have behavior
> linked to its type.

And it is still used today within the simulation community.
We have a fairly active Simula group at work doingnetwork
analyses.

> Other people saw this (Smalltalk), then copied the system (which 
> they
> were incidentally using to build Smalltalk at first), but not to
> simulate real world objects,

Quite a lot of the early Smalltalk stuff did indeed copy real
world objects but they also saw the potential in modelling
virtual objects like the UI elements. They were using Smalltalk
to teach/experiment with young children by that time and the
correspondence between real objects - like pens - and
computing devices was a beneficial side effect.

> When Bjarne Stroustrup made C++, he copied some of the ideas in 
> order
> to make a better type system, where the functions that operated on a

Yes, although he was actually using the tool to build a simulation.
That's why he started with Simula...

> "Object-oriented programming is programming using inheritance.

<Nit Pick>
I never agreed with Bjarne on that. There are a number of OOP
environmemnts that implement polymorphism without inheritance
(Actor is one example). So I think he should have said that
"OOP is about programming polymorphically"
</nit pick>

> OO is not a glorified simulation system, and you will feel pain if 
> you
> overemphasize the generalization "Model objects on real world
> objects". Objects do have to have an idea (Cohesion). It is just, 
> that
> idea doesn't have to be congruous with something you can walk over 
> to
> and pick up in the real world.

And this is the key. Objects have responsibilities. The 
responsibilities
should be related to some kind of conceptual thing, but it may not be
a real world thing. But when you start out with objects it's nearly
impossible to imagine non tangible things. And that takes us back
to nouns/verbs. For all its imperfections it works as a way of gettig
people to break down problems into things rather than functions.
The resultant software may well be sub-optimal but that can be fixed,
but if you can build something that works and is based on objects
that is the starting point. Once you build a few you very quickly run
into the analysis-paralysis issues of trying to follow the real world
too far, and start to deviate., That's when you start to find the
abstractions coming out and seeing objects more generally.
But that's a huge jump for most procedural programmers.

> Often it feels like the "Model objects on real world objects" is how
> people are taught so they get the idea of an object. Actually
> designing all code that way is a needless proscription that really
> really hurts many projects.

I agree with this too. It has to be emphasised that it's only a
starting point to identify object candidates, the final solution
may look very different. But in my experience the bigger the
project the closer the abstractions get to reality at least at
the object identity level - the operations and data are likely
to be very different, and underneath that layer will be a wealth
of lower level abstractions unguessed at by nouns/verbs.

But heh, if you get presented with a requirements spec
of 400 pages and over 1000 user storiers (as I just have!) it's
as good a place to start as any! (IMHO of course! :-)
And hopefully no newbies on the tutor list is in any danger
of that happening to them!

-- 
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld
Which is currently dead awaiting a server repair, sorry! :-(