[FRIAM] What is an object?
Prof David West
profwest at fastmail.fm
Wed Jul 18 02:00:30 EDT 2018
Hi Nick,
An object is a specific way to define and design a module and a module
is a tool for segmenting, modularizing, the source code (what the
programmer actually writes, not what the machine executes) for a
program. To parse this assertion - and then to explain how and why
object modularization is different - a quick aside to discuss a program
is in order.
I use 'program' to mean the source code - the lines of COBOL, java, C++,
or Smalltalk that the programmer writes.
I am sure you have seen BASIC programs. The source code consists of a
list, each entry on that list having a sequence number and a BASIC
statement. The computer will execute that program one line at a time in
sequence: the statement on line 1 then line 2 ... Some of the
statements, say the one on line 20 wont tell the computer to do
something, instead they tell the computer to GOTO some other line number
and resume executing instructions. Several different types of control
structures are available. It takes little imagination to realize the
larger the program the greater the difficulty in understanding what the
computer might be doing at any specific time - especially if you also,
simultaneously, need to track the values of numerous variables to see
which branches are active.
Hence the desire for modularization - packaging blocks of code lines
into identifiable units - to simplify the process of reading a program
and the mental modeling of what the program would be doing at any phase
of execution.
Now add Dikstra's famous definition, "a program is algorithms plus data
structures."
The first criteria for defining a module involved grouping lines of code
that were related by prodecure, (essentially all lines participating in
the same algorithm) - hence procedural programming with four kinds of
modules: control, afferent, transform, and efferent.
For various reasons, procedural modularization was unsatisfactory and,
noticing that data structures were more stable over longer periods of
time, data oriented modularization became the norm. You defined an
entity as a data structure with members called attributes and aggregated
all the procedures that operated on that specific data into a module.
A DOS utility is probably written in C or Assembler, neither of which
afford much opportunity for modularization, and is small enough that it
does not need to be broken up.
A tool in Matlab is likely a large program and if you could see the
source code you would see modularization, probably more procedural in
nature than data oriented.
Note that both approaches to defining modules are focused on the program
itself and how it can be broken up and the pieces related to each other.
The same thing is true of "functional programming," i. e. the focus of
design is inward towards the computer.
Then came 'objects'.
First critical difference: an object is not a way to modularize the
program, it is a means for modularizing the World, the problem space.
Second critical difference: one object is differentiated from another
solely on the basis of behavior - what it does, what contribution it
makes to the overall system, what services it provides to other objects.
These two characteristics of objects are why Harman borrows the term for
his Object-Oriented Ontology.
The term Object-oriented programming was coined by Alan Kay and the
metaphor he used to communicate the idea behind the term was was a
biological cell consisting of an encapsulation boundary, inside of which
was all the complexity that allowed the cell to do what it did, and
outside of which was a protocol that allowed other cells to communicate
with and request services from the cell.
Unfortunately, very, very, few in the programming community "got the
memo" and understood what an object was supposed to be, or how it could
be implemented in a programming language. So, it is extremely rare to
find any code, even in Smalltalk, but definitely in Java or C++ that
even remotely resembles the object idea. Alan Kay maintains, to this
day, that the object revolution has yet to happen.
BTW all modules, and all executing programs for that matter, are
intended to be "black boxes" - you have no idea, and do not care, what
is inside of the box, only what outputs the box will provide you in
exchange for what inputs.
Long winded, and I hope not remedial, answer.
davew
On Tue, Jul 17, 2018, at 8:06 PM, Nick Thompson wrote:
> Dave, and anybody else who wants to play.
>
> I have always been puzzled by the question of how one distinguishes an
> object in object programming from a utility in DOS or a tool in
> Matlab. Or any mathematical function, for that matter. You give it
> what it needs, and it gives you what it’s supposed to, and you don’t
> give a damn how it works.>
> Please don’t yell at me.
>
> Nick
>
> Nicholas S. Thompson
> Emeritus Professor of Psychology and Biology
> Clark University
> http://home.earthlink.net/~nickthompson/naturaldesigns/
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
> FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://redfish.com/pipermail/friam_redfish.com/attachments/20180718/cd702399/attachment.html>
More information about the Friam
mailing list