#ObjectOriented
11 messages in this thread
>Do you find OO to be a good method for desingning programs?
When applicable, yes.
>I am supposed to be getting some OO trainning in a few months.
>From what I have seen reading about it so far it doesn't look much
>different from good structured programming.
I'm interpreting your concerns in two possible ways:
(1) that you see structured == OO
(2) that perhaps you already think in OO
Can you elaborate?
When I am designing a program I usually start by looking at what information I
will be using and I design data structures to represent that. Then as the
design progresses I will write functions to manipulate these structures.
From what I have read so far about C++, you put the data and the functions to
manipiulate the data into classes. These look just like the structs that I use
in C apart from the fact that they contain functions as well. There is a lot of
talk about things being hidden and data only accessible to member functions but
I don't see much advantage to this. If you are designing a program it is just
common sense to be careful how you manipulate your data structures, why do you
need some enforcement mechanism to control this? Especially since you are
controlling this enforcement mechanism yourself.
Then there is the polymorphism which looks very dangerous. I'd hate to have to
maintain a program where any of the standard operators may have been redefined
to do something different.
As you can see I have only scratched the surface of OO and I hope that I will
find it useful. The programming part of my course will be in Smalltalk which I
hear is a more "pure OO" language, and it will continue to OO design
techniques.
Peter Wade
Autopiloting from London, England
Hi, Peter,
PMFJI (Actually I'm hoping to learn something; I' haven't yet learned a
language with support for OO programming.)
>>There is a lot of talk about things being hidden and data only accessible to
member functions but I don't see much advantage to this. If you are designing a
program it is just common sense to be careful how you manipulate your data
structures, why do you need some enforcement mechanism to control this?
Especially since you are controlling this enforcement mechanism yourself.<<
I would guess that it keeps you from having to design and remember rules that
help you "be careful how you manipulate your data structures." The rules, to
some extent, are designed for you. You get to design the classes, of course,
so the rules aren't completely determined by the language.
There are also cases in which it gives sensible structure. For example, I've
written a neural net program in C. There are different kinds of neurons with
different functions, and different sets of parameters for each kind. It makes
sense to define a common interface that applies to each neuron type. I defined
a structure that contains the variables that are common to any neuron type, a
void pointer that code for each neuron type can initialize as it sees fit, and
pointers to functions to implement the common functions, like "initialize
yourself," "evaluate your output," etc. The higher-level code can just call
the function pointed to in the neuron's structure without having to "know"
which function to call for the neuron type. The higher-level code is
simplified quite a lot by this, I think. If I had learned C++ I would hope
that it would have been simpler. I don't see this as an enforcement mechanism,
but perhaps I'm wrong.
Clay
>>…structures, why do you need some enforcement mechanism to control this?
>
>I would guess that it keeps you from having to design and remember rules that
>help you "be careful how you manipulate your data structures." The rules, to
>some extent, are designed for you. You get to design the classes, of course,
>so the rules aren't completely determined by the language.
You are correct on both counts. It does go beyond the freedom of choice re
whether to use it or not though. Most "involved data" (ugh) will be better
off for having used said features. It's not so much that you need the
enforcement, but that you want it. It goes beyond just because of
protection from accident (though that's good too). IMO, it's an intimate
part of the composition process.
>There are also cases in which it gives sensible structure. For example, I've
>written a neural net program in C. There are different kinds of neurons with
>different functions, and different sets of parameters for each kind. It makes
>sense to define a common interface that applies to each neuron type. I defined
>a structure that contains the variables that are common to any neuron type, a
>void pointer that code for each neuron type can initialize as it sees fit, and
>pointers to functions to implement the common functions, like "initialize
>yourself," "evaluate your output," etc. The higher-level code can just call
>the function pointed to in the neuron's structure without having to "know"
>which function to call for the neuron type. The higher-level code is
>simplified quite a lot by this, I think. If I had learned C++ I would hope
>that it would have been simpler.
It is! BTW, this seems like a good design. It of course just so happens
that you've implemented it in C, and using things _implementation details_
like you've explained are the right things to do in C. All this is left to
you though, and with no language support. It would be nice to have been
able to express your design in something that look like that way you
mentally envisioned it.
>I don't see this as an enforcement mechanism, but perhaps I'm wrong.
Oh, it involves it, but it is not as exclusive as the raw feature in a
vacuum implies, so you are right.
>When I am designing a program I usually start by looking at what information I
>will be using and I design data structures to represent that. Then as the
>design progresses I will write functions to manipulate these structures.
That always needs to be done in the end. Its this specific ordering where
OO, and other better designs lead to. From where I come from, I could
_NEVER_ understand my teachers when they delved [exclusively and hence
narrowmindedly] into the marvels of top-down, then bottom-up, then
structured, etc. IMO, that misguided and missed the point.
To me, the idea is to solve the big picture of the problem at hand.
This _indeed_ implies also the necessity to solve the little pictures.
But being _strictly_ data centeric, or algorithm centric, or
functionality-centric (though this latter one should often be up higher in
priority) is not looking at the full picture, whether big or small.
Decomposition (of anything, not just functions) MUST take place, however,
attempts should occur for that not to happen in a vaccum. There are various
relationships in a program, and when possible, it should be united
sub-systems (whatever that happens to be at the time, whether a class,
or a whole chunk of code) not disjoint one. Slightly related, think of
where all the funky wacked out APIs these days are coming from.
>From what I have read so far about C++, you put the data and the functions to
>manipiulate the data into classes.
You can.
>These look just like the structs that I use
>in C apart from the fact that they contain functions as well.
Yes, in fact, in C++ (except for a few syntactic corners of the language)
a struct is a class.
> There is a lot of talk about things being hidden and data only accessible
>to member functions but I don't see much advantage to this.
Why? Do you mean to tell me that you never use local variable in your
functions? Have you ever used C's static? Don't you use multi-.c files
each including respective .h files? It's simply just another dimension of
encapulation, except it is no longer in the exclusive control of the
discipline of the programmer (if s/he so chooses that is).
>If you are designing a program it is just
>common sense to be careful how you manipulate your data structures,
Yes, people write programs, they don't write themselves, so yes, everything
we do should be with caution (at the least). Nonetheless, that does not
necessarily discard any possible language support for some things.
>why do you
>need some enforcement mechanism to control this? Especially since you are
>controlling this enforcement mechanism yourself.
Why do I need a seatbelt in my car? A railing on my stairway?
I don't have to use either, but they are there for the using.
Or, better from a language perspective: I don't need function prototypes,
I always call my functions with the right arguments. Even if you could
show you've never done it incorrectly, how do you go about handling things
like code maintenance? Do you lock you code in a vault and not let anybody
else get at it? What do you do when your 1 million Lines of Code (LOC) app
fails and you boss want the fix NOW, and then there are hundreds more to go?
I dunno about you, but I certainly want the "locality" of something like a
class where my functions and data are intimately related (and BTW, this
alone does not get you off the hook about being cautious with the use of
your data) and the "protection" of not jumping into a Q&D fix as easily.
Here's another classic case: you buy a 3rd party library, and it contains
a bug. You DON'T want to go about zapping global objects and stuff
as convenient and harmless as it appears.
These situations are vast, and real. The option of the enforcement is up to
the programmer. I'm sure you have not prototyped all your own functions
as () (meaning, it is undefined what the arguments to this function are).
Consider things like types of the member changing too.
Or, that the raw value in the member is not the value you want.
You also discard that some things (data, functions, types, etc) are for
implementation details only, and only serve to muddle and introduce bugs
if just any function can start using and calling them.
Surely you must agree with the danger of all these situations, and hence the
benefit of the protection. I know some folks resent hand-holding,
especially extensive hand-holding, but a little hand-holding doesn't really
hurt much and as in the above can actually help lots.
You may even also want to consider that the enforcement is not that at all
but indeed categories of usage for the various parts of your code.
It definitely makes a lot of sense.
>Then there is the polymorphism which looks very dangerous. I'd hate to have to
>maintain a program where any of the standard operators may have been redefined
>to do something different.
As mentioned, abuse of any feature can be dangerous among other things.
Polymorphism in C++ usually refers to virtual functions though,
and that is no less dangerous than using any other feature.
>As you can see I have only scratched the surface of OO and I hope that I will
>find it useful.
To each his/her own. You do seem open-minded enough though that I think
you'll get something out of the effort.
>The programming part of my course will be in Smalltalk which I
>hear is a more "pure OO" language,
Yes, though as with everything that is a compromise.
> and it will continue to OO design techniques.
This is really the issue at hand. In the end, we have to start with a
pliable and useful design for what we're doing, and hence, it's the old
noggin that's of primary importance. You will find though, as you scratch
this surface deeper and deeper that classes, and their respective
capabilities (whether C++, Smalltalk, or some other OO lang) will match your
designs closer. Often, the language is a preferred method of expressing the
design directly. Even private/protected/public come into play.
It's not straighjackets, it's just soft bumpers. This all ties back into
the comments at the start of this message. For instance, it does me little
good to be finished with the information, and hence having already written
the data structures, when for instance, I have no looked at what my
functionality needs to be, who my users will be, how extensible the code
needs to be, how long the code will be expected to be used, etc.
As such, I'd rather not design or write data structures or functions
before looking at functionality, the big picture, tradeoffs, etc.
This upfront "cost" pays. One of the "big lies" (or non-truths) because
folks "forget" to tell you is that it is possible for this to backfire.
Sometimes it's big, sometimes it is not, often it is workable.
Another big lie that programmers go like zombies at is to just go from one
step to the next. That's simply ridiculous. Programming (that is, all it
entails) is a dynamic, iterative process, it's simply gotta be, and as such
things evolve, not remain as stagnant garbage simply because somebody with a
larger mouth says it is good stuff. (Hmm, woops, I'm starting to get myself
up on a soapbox…. guess I'll get on to the next message :-}).
> Why? Do you mean to tell me that you never use local variable in your
> functions? Have you ever used C's static? Don't you use multi-.c files
> each including respective .h files? It's simply just another dimension
> of encapulation, except it is no longer in the exclusive control of the
> discipline of the programmer (if s/he so chooses that is).
When you put it that way, yes it does make sense. I suppose its a case of
terminology, I consider local variables and statics as a way of avoiding
confusion (I have a personal rule that certain variable names like i and j are
NEVER global).
> You may even also want to consider that the enforcement is not that at
> all but indeed categories of usage for the various parts of your code.
> It definitely makes a lot of sense.
Thinking about it more, I suppose you could use it as a more flexible way of
keeping things seperate, like using statics without having to put everything in
seperate files. Obviously I have a lot to learn…
Peter Wade
Autopiloting from London, England
>When you put it that way, yes it does make sense. I suppose its a case of
>terminology, I consider local variables and statics as a way of avoiding
>confusion
But, indeed, that's part of it here too. I suspect you unfamiliarity
is throwing you a curve somehow.
>(I have a personal rule that certain variable names like i and j are
>NEVER global).
I even prefer to avoid them as locals, but surely yes, they'd never be
globals with this names. Anyway, it isn't the name itself that provides the
encasulation, its things like its place'age (for instance, scope).
As previously mentioned, in C, we had minimal support: .c/.h, static,
local variables (whethere static or not), and function prototypes
(borrowed directly from C++ BTW!). We also have: functions,
structure members, (barely) typedef, { … }'s, pointers.
Certainly you cannot go stomp on a local variable (even a static)
in a function, by name, from outside that function w/o having made its
address known somehow. That definitely involves abstraction (usually not
thought this way, but a function definitely involves facets of abstration)
and encapsulation (black boxing providing a public interface, and what
happens "inside" is "of no concern" (philosophically that is, of course in
the real world, it can be of concern, for instance, it might be too slow).
Anyway, C++ really only add a few things to this: public/protected/private,
C++ namespace's ("recent addition"), and static members. But oddly,
these "trivial" additions takes C's bare support to something quite useful.
>> You may even also want to consider that the enforcement is not that at
>> all but indeed categories of usage for the various parts of your code.
>> It definitely makes a lot of sense.
>
>Thinking about it more, I suppose you could use it as a more flexible way of
>keeping things seperate, like using statics without having to put everything in
>seperate files.
Absolutely. Private doesn't just mean "outsiders cannot touch me"
but "for the class use only". That may sound the same but its the
seperation that's important here too.
>Obviously I have a lot to learn…
We all do. It takes a lifetime. Don't feel disappointed 🙂
>>When I am designing a program I usually start by looking at what information
I will be using and I design data structures to represent that. Then as the
design progresses I will write functions to manipulate these structures.<<
Exactly what I do. When I wrote my accounting package, I designed all data
structures first and only then made my programs.
>>From what I have read so far about C++, you put the data and the functions to
manipiulate the data into classes. These look just like the structs that I use
in C apart from the fact that they contain functions as well. There is a lot of
talk about things being hidden and data only accessible to member functions but
I don't see much advantage to this. If you are designing a program it is just
common sense to be careful how you manipulate your data structures, why do you
need some enforcement mechanism to control this? Especially since you are
controlling this enforcement mechanism yourself.<<
I have taught a course in C++ programming techniques. The trouble with C++ is
that it is a complex language. So complex that you cannot possibly know
everything about it?
>>Then there is the polymorphism which looks very dangerous. I'd hate to have
to maintain a program where any of the standard operators may have been
redefined to do something different.<<
When I learned to program 17 years ago, I started with BASIC. A few years
later, PASCAL, became “popular'' and I was laughed at because of the
ambiguities in BASIC.
example: A = B should be written like LET A = B because it is not a real
equation.
PASCAL is much better because you have to write A := B which is much better.
BASIC is horrible because of the ambiguity between A = 12 + 5 and A$ = B$ + C$.
The same people who said this nonsens know find it very professional to
redefine about every operator that exists.
Their logic deludes me completely.
Bart Van Bockstaele at 100574.2352@compuserve.com
… On AutoPilot and Amiga all the way from Belgium NOT from Mars!…
Hi Peter
At this point, may I jump in and say that while OOP may display a lot of
commonality with modular and structured programming, it is much more than that,
and it is a (common) mistake to use it simply as a neat modular technique. As
you say, that alone is not too much, but persevere, there be hidden treasure
here! I think you will enjoy learning Smalltalk. It is the fist language I
used when I started in OOP, and I am glad I did so.
What I found happened to me, was a period of about two months of headbanging as
I tried to force my old style into OOP (it wouldn't go) and then a slow but
steady period of illumination as I started to "click" into the idea of mapping
the real world onto the objects. In this sense every OOP program is an
(elegant – hopefully) simulator.
The OOP features which you mention are OK, but they are not what is now
commonly called OOP – i.e. encapsulation, etc. tend to be called Object-Based
programming these days, and are only a subset of OOP. The main OOP feature is
INHERITTANCE, which allows you to build a hierarchy of classes starting from
the most general, and then specialising, keeping what you need from the
"parents". This is NOT the hierarchy of the components of your program, but
the hierarchy of their structure! (Not unlike the Linnaen hierarchy used to
classify living things according, to phullum,class,genus,family etc.) The best
book I have found on this is Booch's "Object-Oriented Analysis and Design –
with Applications") You can also learn a lot about OOP by studying the Amiga
Exec!
I also think you misunderstood polymorphism. What you are describing, I think,
is operator overloading, which is permitted in C++, although it is almost never
used, unless you are designing a new module sub-language (and then it is
brilliant).
Polymorphism in C++ allows you to give a pointer to a common parent class,e.g.
Vehicle, and then send a message to that class, e.g. Move(). Then the vehicle
will move according to its internal specification, e.g. a car will drive, a
boat will sail, a plane will fly, etc. This reduces the necessity for C
structs like unions. Pollymorphic code is executed by examining the pointer
type at run-time, and so, in a way, it is interpretted. This introduces a great
deal of programming flexibility, with little overhead.
All the best in your OOP endeavours
Alex
greetings…. I am alittle new and have not read alot of the messages. I just
got my SAS C to work right, now I'm ready to consider getting C++ going. I have
taken this and used Borland, naturally. What are my options: GNU C++?
If you have SAS 6.50 this can compile C++. It is not as up to date as some
other compilers, it does not include templates or exceptions.
Peter Wade
Autopiloting from London, England