What is OOP?
john...@nospam.com.au
I have read a few introductions to OOP and found them incomprehensible,
but I suspect that perhaps OOP is primarily about painting the GUI
screen whilst procedural programming is primarily about logic and
arithmetic.
Is this how you see it?
Craig
I assume you are on the outside looking in at programming and are not
really understanding the differences between the Object Oriented
approach and Procedural programming.
The first thing to understand is there is no silver bullet to
programming and procedural programming is often more suited to a problem
than OO. However, OO offers the programmer the opportunity to abstract
the "system" in discrete entities called objects. This makes it easier
to understand the system as objects have an internal state and a
behavior that allow a more natural model of the real world to be
constructed. It also allows a hierarchy to be built of objects that
share a common ancestry. This reduces the need to replicate code when
the same or similar operation needs to be performed in several places.
You can just inherit an object from and ancestor with the desired
behaviour and add in the extra properties or behaviour you need. With
Java you don't even need the source code of the ancestor to do this!
No this is a common misconception. Most GUI code is written in C which
is not an Object Oriented language yet you can create "objects" with it.
OO is just as reliant on logic and arithmetic. You can't write a
program without Logic and the same goes for arithmetic. Computers are
number crunchers and rely on logic to guide the calculations.
I guess what OO boils down to is it gives you the ability to create a
living system that is composed of sometimes related objects that all
exhibit behaviour, they can do something, and state, they have
properties ( like height, width colour etc. Objects talk to each other
reacting to the changes in the system either internal or external,
perhaps a user, in a non-linear way. The code in a well designed OO
system has multiple paths of execution which are almost random in the
order they may be executed. Whereas the more paths of execution in a
procedural program the more complex the system becomes until it gets
beyond ones comprehension.
Theres bound to be lots of discussion of this and my explanation is not
as robust as it could be but I hope it helps you understand.
Craig
Dave Null
>
> I have read a few introductions to OOP and found them incomprehensible,
Old Paint. New cans.
Craig
This quote from "The Joy of SmallTalk" perhaps sums up better than I can
put it.
> The reason for this is that the OO paradigm best satisfies demands for fast development of reliable
> and maintainable software. Its principle of viewing software as modules modeling real world objects is a
> natural reflection of both clients’ and developers’ view of the world, and provides a basis for building
> extendible and reusable libraries of individual objects and whole frameworks that can be relatively
> efficiently extended or customized to build new applications.
I would add that the maintainable part of it is paramount for systems we
need to use fo extended periods. Remember the Y2K furor? Most of the
problems there were not related to the actual omissions in the code but
actually finding all the problems. I remember someone quoting the
number of "goto" statements found in a piece of legacy health system
software that was being upgraded for Y2k and it was well into the tens
of thousands. For everyone of those statements someone had to follow
the code through the system to find all the faults. They never did it.
It was cheaper to replace the system with a new system even though all
the hardware needed replacing also.
Craig
john...@nospam.com.au
Thanks for taking the time to reply.
I see and understand inheritance in the Describe window for setting
styles.
However the common explanations of OOP do have a smell of old paint. I
see all computer code as being reusable, and functions and subroutines
as being orders of magnitude more reusable than main programs.
Back when I was feeding punched cards into System 360s, we compiled
source code and linked the function and subroutine libraries which were
in object code (no DLLs then). I don't know how that usage of "object"
relates to current usage.
Classes of objects and their properties smell very much like the data
dictionary in the DOS database that I bought when the PC XT was leading
edge technology. I am still using that database because it models the
business beautifully (maybe I organised the business to suit the
capabilities of the database, but either way I am happy with the
result).
"Encapsulating methods with data" seems to imply that the code used for
extending and posting selling prices will be replicated in every
transaction record in my database. Surely they don't mean that.
The GOTO statement was deprecated decades before Y2K. That the program
you referred to was still in use in 2000 is testimony to something, but
I am not sure what.
My reason for raising the topic is the inclusion of Object Rexx in Warp
4. What am I missing if I stick with Classic Rexx?
Bob Eager
> However the common explanations of OOP do have a smell of old paint. I
> see all computer code as being reusable, and functions and subroutines
> as being orders of magnitude more reusable than main programs.
>
> Back when I was feeding punched cards into System 360s, we compiled
> source code and linked the function and subroutine libraries which were
> in object code (no DLLs then). I don't know how that usage of "object"
> relates to current usage.
Very different. You are referring to 'object' vs 'source', and using
libraries of 'object code'. (yes, I did all that too)
An 'object' in OOPis an entity, whether compiled or not. So, there is
object source code and object object code!
The difference (crudely) between simple use of libraries, and use of
objects, is great. Simple libraries do, sure, allow re-use of code. What
they don't allow, without recompilation after editing, is use of
modified versions of that code. That's what inheritance is all about.
Another point is that you can have many instances of a class (i.e. the
same kind of object but with different attributes, but the same
behaviour). The nearest approach in 'simple' libraries would probably be
re-entrant code, but this falls far short.
In summary...old paint? No.
--
Bob Eager
rde at tavi.co.uk
PC Server 325*4; PS/2s 9585, 8595, 9595*2, 8580*3,
P70, PC/AT..
Duane Bozarth
Another point is that the problem of name collision in simple object
libraries is a limiting factor in reuse that is alleviated via OOP
(although not <necessarily> totally eliminated).
As for "old paint", I agree that the simple answer is still "No", but
there's certainly a lot of hype even yet that isn't fully justified.
Holger Veit
[...]
> Another point is that the problem of name collision in simple object
> libraries is a limiting factor in reuse that is alleviated via OOP
Ah yes? It basically revolves around the old idea not to call your
favorite tool library "libc.a", because someone else already has called
an important library this name. Whether there is some "namespace"
definition or even some hierarchy of namespaces, doesn't solve the
problem at all; it just remains the old wine in new bottles named
"choose different names for different entities, or you get burnt".
It's pure convention, not at all OOP.
> (although not <necessarily> totally eliminated).
> As for "old paint", I agree that the simple answer is still "No", but
> there's certainly a lot of hype even yet that isn't fully justified.
Given the first experiments on OO coming from LISP systems in the 60s,
it is well old paint. That programming is still regarded as an art and
not engineering, leading to periodically upcoming great "new"
"silver bullet" approaches to solve everything, is the real problem.
Unfortunately, OOA/OOD/OOP will help there as much as writing software
in COBOL which was advertised as "completely understandable to anybody,
because programmers will write clear English sentences."
Holger
Menno
For some reason, I've decided to inject my own opinions into this
thread... I intend to be rambling on for quite a while so get some
coffee and get comfortable ;)
john...@nospam.com.au wrote in message news:<c1.2c.2mZtVW$0...@PC1.ACENET.COM.AU>...
Heh! You may well be forgiven for thinking that, but that's probably
because people these days have a user interface fixation. Object
Oriented Design and Programming (OODP as life's too short) is not a
GUI tool. It's more a design philosophy. Much ink has been wasted[1]
on the subject.
OODP is the evolution that came from:
1. It WORKS!!! How? I dunno!
2. "Structured" programming where you *indent* your loops and
statements. (Real programmers don't use Pascal).
3. Programming with a *design*. Books and books of "methodologies"
exist. "Jackson structured programming" springs to mind.
Once programmers got to that stage, we had basically two design
philosophies: Top down and Bottom up. Top down would helicopter over
the program's requirements, then slowly break these things down into
smaller and smaller components until you arrived at the stage where
you could actually write the code. Bottom up was where you made huge
lists of things you would need and could implement, then combined
those into larger modules until you had something a user could
understand.
Now the problems with top down design was that you could run into
trouble if you didn't do your breakdown right[2]. The problem with
bottom up design was that in big designs, people end up doing the same
things twice in interestingly different ways.
Another worrying trend was for one programmer to look at another's
source and to start poking in their data structures. Then programmer A
would change something to the data structure and chaos would ensue.
OODP was the next thing. And of course, a buzzword like no other[3].
It allowed you to protect to some extent the internal representations
of the "Things your program was about". It allowed you to produce, in
a single package, a representation of things in the outside world,
with clearly defined boundaries. (This is public, you can do with it
what you will. This is private. Hands off). You could "publish"
objects as a black box and have people include them in their own
applications. Visionaries and preachers appeared. Lists of desirable
features in software were written and OODP was put in under
"Solution". And that is why today, computers are the smooth and
trouble-free tools that they are. Um.
<fx; Turns the "Universe" knob to the right setting>
So that's more less than more where OODP came from. "But!", I hear you
cry out, "What the heck IS it?". Well.
Object oriented design in This Writer's opinion, is a design based on
"Objects", what's in the objects and what you can do to/with the
objects. A kettle, for instance, contains "On/Off switch", "Amount of
water" and "Temperature of water". If for some bizarre reason you want
to model a kettle using OODP, you'd have this:
Object: Kettle.
Private contents:
Amount of water
Temperature of water
Private operations:
Heat
Public operations:
Fill it up (Interface with Tap object)
Pour it out (Interface with either Teapot or Cup object)
Turn it on
Turn it off
Now for a nice cup of coffee, you'll fill up the kettle, then turn it
on. The "Turn it on" operation starts the "Heat contents" operation,
which the user of the object can't get to. (Experiments using a
blowtorch were disappointing). This process will heat the water until
the temperature hits "Boiling". Then it'll use the "Turn it off"
operation and you can use the "Pour it out" operation. Now the
"Operations" I keep talking about are called "messages" in OODP. The
"Contents" items are called "members" (among other things). So there
you have it. An object oriented kettle. And they said OODP was
useless! Hah!
So now we come to the workhorses of OODP: Data Encapsulation,
Inheritance and Polymorphism. Let's boldly press metaphors where no
metaphors have gone before.
Data encapsulation means that you don't access any private members,
except through messages. There are good reasons for this. If you just
let anyone change whatever member you have, whenever, the wrong values
might get in (shudder). Messages (glorified functions) can check input
values and reject the wrong values. Another reason for data
encapsulation is that you can change things inside the object without
telling the outside world. As long as the message stays the same,
you're OK. So in many objects, you'll see a string of setfoo() and
getfoo() messages. So use the things! If you try to measure the
temperature of the water using your thumb, you may get burned!
Inheritance is mostly a labor saving construct. It is used whenever
you have lots of similar objects and to create two objects, you'd have
to cut & paste the same message into lots of different objects and
keep them in sync. What you do is to create one object (Water heater).
Then, you say "Okay.. A Kettle is a Water Heater, but this is
different about it". I'm using this in my user interface classes[4]. I
have one class called "Control", from which I've derived "Entry
field", "List box", "Scroll bar", "Slider" and so on. For each
control, I just redefine "Create this control" and add some specific
code (for instance to add a page to a notebook). Now when I decide
that what my controls really need is to have a message that changes
their colour, I need only add it to "Control" and I'm set for all
controls.
Polymorphism means sending the same message to different objects.
F'rinstance, if you have many objects that have a name, they would
share a message called "Set Name". If you want to impress people at
parties[5], ask them if they use dynamic or static polymorphism.
Static polymorphism happens when several, mostly unrelated, objects
hapen to have the same message. This is more of a convention than a
programming construct, really. Dynamic polymorphism is much more fun.
It allows you to send the same message to objects that the caller
doesn't even know!
The classic example is the graphics program. You have one object
called "Shape". You define some basic operations that you might want
to do on shapes (Draw them, get their size, rotate them, squeeze them,
please th-). Then, you create shapes like "Rectangle", "Triangle",
"Line", "Column graph" and so on, and derive them (inheritance!) from
"Shape". Now every shape will be "born" with the same messages as
"shape", but of course, you draw a triangle in a different way from a
square, so you need to supply the "draw" message for every shape. Now
the bit of your program that draws your drawing doesn't know or care
about circles, triangles or flowers. All it does is make a list of all
the shapes, and send them a "draw" message. This means that you don't
have to change the drawing bit of your program when you add a new and
exciting shape. This also makes your drawing routine less complicated.
So together, data encapsulation, inheritance and polymorphism make
your programs less likely to break down when something changes,
shorter and easier to maintain.
Many people will insist that you really need Smalltalk to do proper
OODP, but I'm of the opinion that you can do OO even in assembler if
you want. It's more of a design philosophy than a design environment.
An OO programming language does make the job easier, though. There are
many excellent OO programming languages out there (remember Ada?) but
sod 'em all, I use C++. C++ is C with object oriented additions. It
rests nicely with all OO thoughts, but in a pinch, it'll still allow
you to do things decidedly non-OO if work needs to be done. The thing
that was added to C to make it object oriented is the Class. Think of
a class as a struct on steroids. Just as you create structs in memory,
you create "instances" of a class using the "new" operator or by
declaring an object as a variable like you do with structs. Classes
have three areas: private, protected and public. Private is where only
objects of the class itself may go[6]. Protected is for the class
itself and any of its derived classes. Public is free for all. Whereas
in a struct, you can only have data members, in a class, you can also
have member functions. A member function's definition "int
getnumber(int i);" is called a "message". The bit of code that
actually gets the number is called a "method".
And that, in a nutshell, is OODP.
Thank you for your attendance. Next week, we do... System development
methodology!
Cheers/2,
Menno
==== [Feetneet] =========================
[1] And electrons severely inconvenienced
[2] How does a top down designer put five elephants in a VW beetle?
Two in the front, three in the back.
[3] There's a story about object oriented kittens...
[4] Yes, I also have a user interface fixation. But I'm getting
better!
[5] Dude! You go to some weird parties!
[6] And its friends, but I'm a bastard and have no friends.
--
This post took two cups of coffee to make. I'd like to day that no
animals were hurt in the making of this post, but I swatted one fly.
Thomas Vandahl
news:ccdb0209.03071...@posting.google.com...
[...]
> And that, in a nutshell, is OODP.
>
> Thank you for your attendance. Next week, we do... System development
> methodology!
Great stuff to read. I like the kettle example...
By all means: Continue this lesson! :-)
Bye, Thomas