Ping Stefan Ram - Teaching object orientation without depending onreal-world objects

[Tom Anderson]

Stefan! And everybody else ...

I came across this question round the back of StackOverflow today
(disregard the bit about the origins of OO, which is immaterial whether
it's true or not):

http://programmers.stackexchange.com/q/59073/854

Quoting selectively, the poster asks:

How might one teach OO without referencing physical real-world objects?

[...] it made me wonder if there is a way of teaching OO without the
(Bike, Car, Person, etc.) object analogies, and that instead focuses on
the messaging aspects.

I may be imagining this, but weren't you asking about something similar a
few months ago? I vaguely remember a discussion about how you might do
this, its desirability, and so on, that i thought was pretty good, and is
likely a pre-tread of the discussion that will emerge on Programmers.

If i'm not imagining it, and if that thread is archived on Google, i'd
like to post a link to it on that discussion.

Cheers,
tom

 

[markspace]

[...] it made me wonder if there is a way of teaching OO without the
(Bike, Car, Person, etc.) object analogies, and that instead focuses on
the messaging aspects.

I think several of us opined a while back that more abstract objects
should be included in teaching OOP. Teaching only models for physical
objects gives students the wrong idea that OOP is all about modeling
physical objects, when it's really not.

I think design patterns would be a better place to start. There are
some easy concepts (Facade, State Machine, Decorator, etc.) that could
be studied. They're real patterns so they are useful latter in one's
studies and career.

One should also teach, from day one, the discovery process that one goes
through as one breaks down a design or requirement and how that
decomposes into various objects. Design Patterns are breakdowns of real
requirements (the GoF book goes into some detail on each one) so they
make excellent cases to study.

There's also some programming patters that occur often. In Java, the
Collections API makes a good introduction to inheritance and OOP.
Coding to an interface:

List<String> list = new ArrayList<String>();

is a common and useful pattern.

Etc.

 

[Daniele Futtorovic]

[...] it made me wonder if there is a way of teaching OO without the
(Bike, Car, Person, etc.) object analogies, and that instead focuses on
the messaging aspects.

I think several of us opined a while back that more abstract objects
should be included in teaching OOP. Teaching only models for physical
objects gives students the wrong idea that OOP is all about modeling
physical objects, when it's really not.

Still, it is about modelling. And I would assert that for most people
without prior knowledge of modelling (as one would assume should be the
regular case it matters of teaching), starting with physical objects
will provide the approach of the subject they can mostly relate to.

The indispensable trick then is, starting from physical objects, to
abstract and especially to *learn to* abstract.

And then to model, that is to combine and arrange, abstractions.

Three step process: topic -> analysis -> synthesis.

 

[markspace]

starting with physical objects
will provide the approach of the subject they can mostly relate to.

I think the crux here relies on the word "starting." It depends on how
long, exactly one relies on the metaphor of physical objects before
expanding on that concepts.

I remember learning to program, I don't think we modeled any physical
objects to begin with. I learned basic procedural programs at first.
Those relied much more abstract concepts. Programs were composed of
functions and procedures (algorithms). Both of those relied on
mathematical metaphors, which are pretty abstract concepts.

Then later, in a data structures course, we moved on to stacks, lists,
queues and trees. Somewhat rooted in physical objects but the actual
implementation we used was very abstract, much more driven by the needs
of the program and in no way modeled any kind of actual physical object.

So I was going to agree with you, but I think now I've convinced myself
that I shouldn't. Students are perfectly capable of learning abstract
concepts right from the get-go, and have been learning that way for a
good 40 years before the introduction of OOP. I think learning about
physical objects is an unneeded and unwarranted detour on a student's
path to understanding.

To conclude, my opening question about how long one should study
physical objects, the answer is zero.

 

[Daniele Futtorovic]

I think the crux here relies on the word "starting." It depends on how
long, exactly one relies on the metaphor of physical objects before
expanding on that concepts.

I remember learning to program, I don't think we modeled any physical
objects to begin with. I learned basic procedural programs at first.
Those relied much more abstract concepts. Programs were composed of
functions and procedures (algorithms). Both of those relied on
mathematical metaphors, which are pretty abstract concepts.

Then later, in a data structures course, we moved on to stacks, lists,
queues and trees. Somewhat rooted in physical objects but the actual
implementation we used was very abstract, much more driven by the needs
of the program and in no way modeled any kind of actual physical object.

So I was going to agree with you, but I think now I've convinced myself
that I shouldn't. Students are perfectly capable of learning abstract
concepts right from the get-go, and have been learning that way for a
good 40 years before the introduction of OOP. I think learning about
physical objects is an unneeded and unwarranted detour on a student's
path to understanding.

To conclude, my opening question about how long one should study
physical objects, the answer is zero.

Fair enough.

But also note that OOP is a part of general programming, not a substitute.

 

[Arved Sandstrom]

[...] it made me wonder if there is a way of teaching OO without the
(Bike, Car, Person, etc.) object analogies, and that instead focuses on
the messaging aspects.

I think several of us opined a while back that more abstract objects
should be included in teaching OOP. Teaching only models for physical
objects gives students the wrong idea that OOP is all about modeling
physical objects, when it's really not.

I think design patterns would be a better place to start. There are
some easy concepts (Facade, State Machine, Decorator, etc.) that could
be studied. They're real patterns so they are useful latter in one's
studies and career.

One should also teach, from day one, the discovery process that one goes
through as one breaks down a design or requirement and how that
decomposes into various objects. Design Patterns are breakdowns of real
requirements (the GoF book goes into some detail on each one) so they
make excellent cases to study.

There's also some programming patters that occur often. In Java, the
Collections API makes a good introduction to inheritance and OOP. Coding
to an interface:

List<String> list = new ArrayList<String>();

is a common and useful pattern.

Etc.

I agree with the above in general. I see starting with modelling
physical objects as starting at the wrong end of the problem.

DCI (Data-Context-Interaction) proponents, of whom I am one, would have
it that much of OOP has suffered for a long time because of the idea
that if your "concrete" *things* are modelled, and invested with
behaviours that belong to those things, that the higher level of program
behaviour will somehow just appear.

There's an unwillingness to acknowledge/realize that there's an entire
other category of "thing" that also deserves - and needs - to be
modelled as objects, and that's behaviour. And by behaviour I mean use
cases - lumps of procedural logic that actually <Gasp> describe what
happens.

Starting from this end, and modelling the use cases as objects first,
then naturally leads to a consideration of roles. In Java it's then easy
to start thinking about interfaces.

Design patterns enter better at this stage *and* from this direction -
to my way of thinking - than in the much more common manner of employing
them _after_ modelling data and data-associated logic, and then somewhat
desperately trying to save the emerging mess with patterns. Much better
to deploy the design patterns to start realizing your use case objects
and roles objects, not to somehow stitch your data model objects together.

I'll wager money that the majority of OOP practitioners still wish that
all those objects that look awfully like bundles of imperative+
procedural programming would just go away. Failing that, let's not
dignify them with official recognition. In fact they should be the
starting point of design. IMHO.

AHS

 

[Arved Sandstrom]

[...] it made me wonder if there is a way of teaching OO without the
(Bike, Car, Person, etc.) object analogies, and that instead focuses on
the messaging aspects.

I think several of us opined a while back that more abstract objects
should be included in teaching OOP. Teaching only models for physical
objects gives students the wrong idea that OOP is all about modeling
physical objects, when it's really not.

I think design patterns would be a better place to start. There are
some easy concepts (Facade, State Machine, Decorator, etc.) that could
be studied. They're real patterns so they are useful latter in one's
studies and career.

One should also teach, from day one, the discovery process that one goes
through as one breaks down a design or requirement and how that
decomposes into various objects. Design Patterns are breakdowns of real
requirements (the GoF book goes into some detail on each one) so they
make excellent cases to study.

There's also some programming patters that occur often. In Java, the
Collections API makes a good introduction to inheritance and OOP. Coding
to an interface:

List<String> list = new ArrayList<String>();

is a common and useful pattern.

Etc.

I agree with the above in general. I see starting with modelling
physical objects as starting at the wrong end of the problem.

DCI (Data-Context-Interaction) proponents, of whom I am one, would have
it that much of OOP has suffered for a long time because of the idea
that if your "concrete" *things* are modelled, and invested with
behaviours that belong to those things, that the higher level of program
behaviour will somehow just appear.

There's an unwillingness to acknowledge/realize that there's an entire
other category of "thing" that also deserves - and needs - to be
modelled as objects, and that's behaviour. And by behaviour I mean use
cases - lumps of procedural logic that actually <Gasp> describe what
happens.

Starting from this end, and modelling the use cases as objects first,
then naturally leads to a consideration of roles. In Java it's then easy
to start thinking about interfaces.

Design patterns enter better at this stage *and* from this direction -
to my way of thinking - than in the much more common manner of employing
them _after_ modelling data and data-associated logic, and then somewhat
desperately trying to save the emerging mess with patterns. Much better
to deploy the design patterns to start realizing your use case objects
and roles objects, not to somehow stitch your data model objects together.

I'll wager money that the majority of OOP practitioners still wish that
all those objects that look awfully like bundles of imperative+
procedural programming would just go away. Failing that, let's not
dignify them with official recognition. In fact they should be the
starting point of design. IMHO.

AHS

And I might add, if one is not swayed by DCI arguments, there is always
RDD (Resposnnsibility-Driven Design). There are 6 common stereotypes,
one of which is

Information Holder - Knows things and provides information. May make
calculations from the data that it holds.

*This* is the one that we subject all of the OOP newbies to with the
modeling of physical objects. It's the one that many if not most OOP
programmers start with on a new project, and then they use (*if* they
use) design patterns to try and rescue the design of the project.

There are 5 other common RDD stereotypes - Structurer, Controller,
Coordinator, Service Provider, and Interfacer - and these are the
concepts that OO programmers often don't identify well. They are in fact
the more important objects, and they are often realized in real-world
programs, but if you don't embrace them as what they are, then they're
really just afterthoughts, not first-class members of your design.

To go back to Part I (the previous email) I say start people off with
the central object types, not the Information Holders.

AHS

 

[Michael Wojcik]

The indispensable trick then is, starting from physical objects, to
abstract and especially to *learn to* abstract.

And then to model, that is to combine and arrange, abstractions.

Agreed. I'd go so far as to claim that learning to abstract,
manipulate abstractions, and move up and down hierarchies of
abstractions is the primary requirement for learning to write computer
programs.

I'd even claim that it's the primary requirement for pretty much any
sort of knowledge work.

(In fact, I did make this claim, at a dinner party a few months ago,
when the topic of philosophies of teaching came up.)

 

[Daniele Futtorovic]

Agreed. I'd go so far as to claim that learning to abstract,
manipulate abstractions, and move up and down hierarchies of
abstractions is the primary requirement for learning to write computer
programs.

I'd even claim that it's the primary requirement for pretty much any
sort of knowledge work.

I once wrote a paper, back in university, about, I believe it was 15th
century, Chinese mathematics. At that time, much Chinese knowledge had
been lost during the preceding ages, so it was pretty much new ground
for them.

They took the (euclidian) Western maths and kind of replicated them, but
/without/ the euclidian axiomatic, that is, to relate to what we are
speaking here, without (a lot of) the abstractions. And they were able
to replicate it, that is to get to the same results and rules (think
Pythagoras' theorem)... but without the whole supporting grid. Very
interesting stuff. It's probably not very clear from this here my
description, but it left a strong impression on me as to the sheer power
of good models. For, although they did get the same results, their
results lacked one crucial thing: fruitfulness. They had to start from
zero to get to Pythagoras' theorem, and then to start from zero again to
get to, say, differential analysis. They couldn't build on one thing to
get to another, more advanced thing.

 

[Daniele Futtorovic]

I agree with the above in general. I see starting with modelling
physical objects as starting at the wrong end of the problem.

DCI (Data-Context-Interaction) proponents, of whom I am one, would have
it that much of OOP has suffered for a long time because of the idea
that if your "concrete" *things* are modelled, and invested with
behaviours that belong to those things, that the higher level of program
behaviour will somehow just appear.

There's an unwillingness to acknowledge/realize that there's an entire
other category of "thing" that also deserves - and needs - to be
modelled as objects, and that's behaviour. And by behaviour I mean use
cases - lumps of procedural logic that actually<Gasp> describe what
happens.

I'm not convinced the fault lies with the physical objects here, but
rather with the observers, who aren't intellectually trained enough to
differentiate between an object's appearance and its essence.

For instance, thinking of a car as some bulky thing with four wheels and
some handles, rather than looking at its *function* (to get things from
A to B, or perhaps rather to get people stuck in traffic jams between A
and B), and how its various components participate in that function.

If my assumption is correct, then no matter what fancy theories, DCI,
RDD -- both of which I admittedly know nothing about -- you devise to
work around the problem, ultimately you'll always be confronted with it
again.

 

[Arved Sandstrom]

I'm not convinced the fault lies with the physical objects here, but
rather with the observers, who aren't intellectually trained enough to
differentiate between an object's appearance and its essence.

For instance, thinking of a car as some bulky thing with four wheels and
some handles, rather than looking at its *function* (to get things from
A to B, or perhaps rather to get people stuck in traffic jams between A
and B), and how its various components participate in that function.

If my assumption is correct, then no matter what fancy theories, DCI,
RDD -- both of which I admittedly know nothing about -- you devise to
work around the problem, ultimately you'll always be confronted with it
again.

DCI and RDD (and other methods) are simply systems for helping people to
think the way you just described. For example, just because cars are
involved in a transportation problem that you wish to model, how
important is it to model a car at all? The act of moving a thing from
point A to point B is actually your central concern, in which case you
might be asking the thing to move itself from A to B, and for various
segments of the trip the thing may be invested with the modality of
moving by car or by foot or by train...and possibly at no stage do you
really much care about details of cars or feet.

We need to recognize that objects often model processes, not things.

AHS

 

[markspace]

DCI and RDD (and other methods) are simply systems for helping people to
think the way you just described. For example, just because cars are
involved in a transportation problem that you wish to model, how
important is it to model a car at all?

We need to recognize that objects often model processes, not things.

What Arved said.

The idea that *function* of a car is transportation doesn't matter if
you're writing an inventory control program for a car dealership. The
only thing the dealership cars about is how many of each car and what
color (so they can look things up for customers), what their monthly
sales were (so the accountant can pay taxes), and what's been ordered
(so they can manage inventory).

The *function* of a car as tranportation doesn't matter in this case,
only the dealership's requirements do. This is a pretty good example of
why you don't want to model physical objects, I think. It's a detour on
the route towards actually implementing your customer's requirements.
Your requirements inform the objects' methods and properties, not the
other way around.

 

[Daniele Futtorovic]

DCI and RDD (and other methods) are simply systems for helping people to
think the way you just described.

*makes note

For example, just because cars are
involved in a transportation problem that you wish to model, how
important is it to model a car at all? The act of moving a thing from
point A to point B is actually your central concern, in which case you
might be asking the thing to move itself from A to B, and for various
segments of the trip the thing may be invested with the modality of
moving by car or by foot or by train...and possibly at no stage do you
really much care about details of cars or feet.


We need to recognize that objects often model processes, not things.

No, we need to recognise that all things are processes. Even, through
its interaction with other objects and its being subject to natural
forces, inanimate matter. Even, through upgrading and compatibility
issues, data structures.

 

[Lew]

Arved Sandstrom wrote:

What Arved said.

The idea that *function* of a car is transportation doesn't matter if you're
writing an inventory control program for a car dealership. The only thing the
dealership cars about is how many of each car and what color (so they can look
things up for customers), what their monthly sales were (so the accountant can
pay taxes), and what's been ordered (so they can manage inventory).

The *function* of a car as tranportation doesn't matter in this case, only the
dealership's requirements do. This is a pretty good example of why you don't
want to model physical objects, I think. It's a detour on the route towards
actually implementing your customer's requirements. Your requirements inform
the objects' methods and properties, not the other way around.

I agree mostly, but only somewhat for "you don't want to model physical
objects". As Arved said, "often" you don't. Sometimes you do; the inventory
system surely has to. More accurate is, "You don't necessarily want to model
physical objects, nor only physical objects, nor everything about physical
objects."

Or more succinctly, "Model what's relevant for your system."

 

[Lew]

No, we need to recognise that all things are processes. Even, through
its interaction with other objects and its being subject to natural
forces, inanimate matter. Even, through upgrading and compatibility
issues, data structures.

This does not obviate modeling physical objects. It is just as true that
physical objects are processes as it is that model objects are. You seem to
be making that very point if I read your post correctly.

I'm not saying it's 100% true, only that the degree of truth is the same.

I prefer a more conventional ontology, that objects (both real and model) are
things possessed of both attributes and behaviors, and that they participate
in processes rather than that they /are/ processes. From that perspective
your observation would become, "All things are relevant for the processes in
which they participate."

I don't guess that the different ontologies result in much different software.
Both recognize and emphasize the importance of processes.

 

[markspace]

As Arved said, "often" you don't. Sometimes you do; the
inventory system surely has to. More accurate is, "You don't necessarily
want to model physical objects, nor only physical objects, nor
everything about physical objects."

Sure. If a physical attribute is important to your requirements, model
it. Vehicle color and the vin number are two things that a dealership
probably cares about. OTOH, typical beginning properties like has-a
steering wheel and has-a [0..4] tires probably don't matter, as the
sales person will be able to advise a customer based on make and model,
should a question arise.

Or more succinctly, "Model what's relevant for your system."

Yup.

 

[Stefan Ram]

I may be imagining this, but weren't you asking about something similar a
few months ago?

It possibly might be a message from 2010-12-18:

Subject: Searching a motivating example for upcasts
Message-ID: <[email protected]>

, which possibly might not be archived in archives.

There, I wrote:

|I am looking for any real world examples where it is
|advantageous to limit voluntarily the possibilities of some
|object in order to make sure that one uses a general
|procedure on it.

How might one teach OO without referencing physical real-world objects?

I give classes on the programming languages C, C++, Java and C#.

When teaching about OOP in the context of these classes,
I usually do not have the idea that I should reference
»physical real-world objects« at all.

My explanation of OOP might proceed as follows:

It begins with a method invocation (I can assume that my
students already know about this, because I already have
explained this before this point):

f(x)

0 I now can introduce the fundamental distinction between
a client and a service: Usually the method invoker
(caller) is the client and the method invoked is the
service.

1 Also, the method invoked has its private data
(parameters and local variables).

2 Sometimes, it might be useful to extend the life-time
of these data beyond the duration of the call ...
which gives us a kind of object.

3 Sometimes, it might be useful to add additional
calls to this object.

The explanation of paragraph 0 still holds: An object
is a service.

Paragraph 1 already gave us encapsulation, because
the parameters and local variables of a method
(incarnation) are already hidden to the caller.

I also use the common example of a bank account as
an example for an object. This is somewhat
»real world« indeed, but not »physical«.

However, what this post so far has given actually are not
OOP objects, but abstract objects, that is ADT objects.
Possibly, the stackexchange discussion also is about ADT
objects (without the participants necessarily being aware of
this).

OOP begins when one has ADT and then adds the possibility
for polymorphism. But that's another story ...

 

[Tom Anderson]

It possibly might be a message from 2010-12-18:

Subject: Searching a motivating example for upcasts
Message-ID: <[email protected]>

, which possibly might not be archived in archives.

There, I wrote:

|I am looking for any real world examples where it is
|advantageous to limit voluntarily the possibilities of some
|object in order to make sure that one uses a general
|procedure on it.



I give classes on the programming languages C, C++, Java and C#.

When teaching about OOP in the context of these classes,
I usually do not have the idea that I should reference
»physical real-world objects« at all.

My explanation of OOP might proceed as follows:

Aha! Yes, that was it. An interesting discussion, which i was glad to
re-read. Thanks for directing me to it.

tom