Object-oriented question
Tortolo
under procedural languages??
Thanks,
Jairo
Josh Sebastian
wrote:
>How object-oriented programming allows for easier code reuse than
>under procedural languages??
It doesn't. It is equally easy to reuse an existing module in a
procedural language as it is in an OO language. What OO does is make
it easier to *write* reusable code.
- the properties and the methods are easily packaged together
(encapsulation)
- implementation details can be hidden from the programmer-user
(information hiding)
- extensibility features (inheritance, dynamic binding)
Josh
Richard Heathfield
>
> On 7 Jul 2002 10:00:07 -0700, jcar...@ecopetrol.com.co (Tortolo)
> wrote:
>
> >How object-oriented programming allows for easier code reuse than
> >under procedural languages??
>
> It doesn't. It is equally easy to reuse an existing module in a
> procedural language as it is in an OO language.
Good answer, Josh. (As someone-or-other almost said recently, code
re-use dates back to when mammoths were employed as card-punch
operators.)
> What OO does is make
> it easier to *write* reusable code.
Oooooh I think we'll have to agree to disagree there. I would very
quickly agree, however, that OO makes it easier for /some/ people to
write reusable code.
<snip>
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Josh Sebastian
<bin...@eton.powernet.co.uk> wrote:
>Josh Sebastian wrote:
>>
>> What OO does is make
>> it easier to *write* reusable code.
>
>Oooooh I think we'll have to agree to disagree there. I would very
>quickly agree, however, that OO makes it easier for /some/ people to
>write reusable code.
No agreement to disagree necessary. Consider my statement emmended.
Josh
Dan Tex1
>Date: 7/7/02 10:28 AM Pacific Daylight Time
>Message-id: <jiugiu04e006ejjgo...@4ax.com>
>
>On 7 Jul 2002 10:00:07 -0700, jcar...@ecopetrol.com.co (Tortolo)
>wrote:
>
>>How object-oriented programming allows for easier code reuse than
>>under procedural languages??
>
>It doesn't. It is equally easy to reuse an existing module in a
>procedural language as it is in an OO language. What OO does is make
>it easier to *write* reusable code.
I agree with Richard's view here. It is easier for some people. I've seen too
many people screw up OO codes to even attempt to make a similar generalization.
By the way... I believe there is more reusable fortran code available than
exist for any other language ( by a very large margin ). Of course... I note
that some people have a totally different definition for "reusable" than I
have.
>- the properties and the methods are easily packaged together
>(encapsulation)
OO isn't needed for this. I do this in standard fortran ( procedural ) quite
easily. Yes... it IS part of the language. I don't need to do anything
special to achieve this.
>- implementation details can be hidden from the programmer-user
>(information hiding)
I also do this easily in standard fortran. Once again, it's nothing
incredibly special. Pretty mundane actually.
>- extensibility features (inheritance, dynamic binding)
Inheritance, I can do to a limited degree in fortran... nothing like most OOP
languages though. As for dynamic binding... truthfully, I'm not really sure
what it refers to ( not being a CSci. major or anything ).
>Josh
As always.... use "a" correct language for the job at hand. Two
languages/styles being equal... use the one you are most comfortable with.
Dan :-)
PS. Approx. 98% of all people I know who have tried to convince me of the
superiority of OOP ( often citing code reuse as a major part of that
superiority ) haven't even been able to describe to me what OOP is. In fact,
they haven't even been able to tell me exactly what an Object is. Do we
really want "All" programming languages to be OOP ( as has been suggested many
times before )?? Go figure!?! ;-)
Josh Sebastian
>>From: Josh Sebastian cur...@cox.net
>>Date: 7/7/02 10:28 AM Pacific Daylight Time
>>Message-id: <jiugiu04e006ejjgo...@4ax.com>
>>
>>On 7 Jul 2002 10:00:07 -0700, jcar...@ecopetrol.com.co (Tortolo)
>>wrote:
>>
>>>How object-oriented programming allows for easier code reuse than
>>>under procedural languages??
>>
>>It doesn't. It is equally easy to reuse an existing module in a
>>procedural language as it is in an OO language. What OO does is make
>>it easier to *write* reusable code.
>
>I agree with Richard's view here. It is easier for some people. I've seen too
>many people screw up OO codes to even attempt to make a similar generalization.
Yes, I stand corrected (or emmended :-)
>>- the properties and the methods are easily packaged together
>>(encapsulation)
>
>>- implementation details can be hidden from the programmer-user
>>(information hiding)
>
>OO isn't needed for this. I do this in standard fortran ( procedural ) quite
>easily. Yes... it IS part of the language. I don't need to do anything
>special to achieve this.
Yup, I didn't mean to imply that those were unique to OO.
>>- extensibility features (inheritance, dynamic binding)
>
>Inheritance, I can do to a limited degree in fortran... nothing like most OOP
>languages though. As for dynamic binding... truthfully, I'm not really sure
>what it refers to ( not being a CSci. major or anything ).
Dynamic binding is calling a different function at run-time depending
on the dynamic type of an object. Use of dynamic binding is what
*makes* a program OO. Without it, it's not OO.
Dynamic binding can, of course, be done in any language (at least, any
language I'm familiar with). You don't need an OO language to write OO
code... but it sure makes it easier :-}
Here's a crude example of dynamic binding in C (I don't know Fortran).
I don't think it invokes undefined behavior, but I'm sure Richard will
let me know if it does :-}
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
struct Foo
{
void (*f)(void);
};
void foo_f(void)
{
printf("Inside Foo::f\n");
}
void* create_foo(void)
{
struct Foo* f = malloc(sizeof(*f));
f->f = foo_f;
return f;
}
void destroy_foo(struct Foo* f)
{
free(f);
}
struct Bar /* "inherits" from Foo */
{
struct Foo base;
};
void bar_f(void)
{
printf("Inside Bar::f\n");
}
void* create_bar(void)
{
struct Bar* b = malloc(sizeof(*b));
b->base.f = bar_f;
return b;
}
void destroy_bar(struct Bar* b)
{
free(b);
}
void foobar(struct Foo* f)
{
f->f();
}
int main()
{
struct Foo* foo = create_foo();
foobar(foo);
destroy_foo(foo);
foo = create_bar();
foobar(foo);
destroy_bar((struct Bar*)foo);
return 0;
}
In this example, the call "f->f()" in the foobar function is an
example of dynamic dispatch. We don't know what function we're calling
until run-time, and the function is dependent on the "runtime type" of
the object.
Take that, EGN :-}
I leave it as an exercise to the reader to implement a destroy(struct
Foo*) function which will destroy both Foo*s and Bar*s correctly.
(Hint: use dynamic dispatch, just like we did with foobar and f. This
is why base casses need virtual destructors in C++ :-)
>As always.... use "a" correct language for the job at hand. Two
>languages/styles being equal... use the one you are most comfortable with.
Indeed.
Josh
Jim Rogers
> Josh Sebastian wrote:
>
>>On 7 Jul 2002 10:00:07 -0700, jcar...@ecopetrol.com.co (Tortolo)
>>wrote:
>>What OO does is make
>>it easier to *write* reusable code.
>>
>
> Oooooh I think we'll have to agree to disagree there. I would very
> quickly agree, however, that OO makes it easier for /some/ people to
> write reusable code.
>
I agree too, and I like some of the OO concepts.
Object Oriented designs often a good idea, no matter how you
implement them. Note that I did not say they are always a good
idea. Some problems are complicated by and OO approach. Some are
helped.
Object-Oriented languages are another issue. Just how good or useful
they are judged to be depends upon your background and expeiences.
An OO language is *supposed* to make it easier to completely implement
an OO design. However, every OO language I have learned has some
procedural syntax. The procedural syntax is used to implement the
OO methods, also known as functions, procedures, subroutines, or
subprograms.
What then, does an OO language provide that is different from a more
purely procedural language? The exact answers differ slightly from one
OO language to another. I will concentrate on some fairly universal
answers.
OO languages offer syntax for encapsulating code and abstract data
designs into a single module. Note that most procedural languages can
do this very well too. The difference in an OO language is that such
encapsulation becomes the "normal" way of designing a program. In some
languages it is the only way to design a program.
OO languages offer syntax to facilitate reuse. Most often the kind of
reuse they emphasize is reuse through inheritance. Inheritance is the
ability to define one abstract data type, and then later use that as
the basis for a related data type. With inheritance you do not need to
explicitly copy or redo the code from the inherited data type.
With this inheritance comes the concepts of overloading and overriding
methods. Overloading methods means defining two or more methods, each
with a different method "signature", which have the same name. For example,
you may define two Print methods. One will take an integer parameter and the
other will take a string parameter. The compiler can determine which
method to call by examining the correlation between the actual parameters
and the formal parameters. Overriding is similar, but more subtle.
When you build a new data type using inheritance, one of the things
you inherit is the methods defined as primitive or "virtual" for that
parent data type. You can then make a new method with the same name as
your inherited method. Again, the signature of the overriding method
must be different than the signature of the overriden method.
Normally, the decision about which method is to be called is made
at run time, not by the compiler. The ability of a language to make
such a determination at run time is variously called run-time dispatching,
or polymorphism.
Note that all these wonderful features require special care and design.
If you do not apply special care and design you will find yourself in a
lot of coding trouble very quickly. A famous quote, reportedly from
Bjarne Stroustup, the author of C++, is "With C you can easily shoot
yourself in the foot. With C++ it is harder to shoot yourself, but when
you do you blow your entire foot off."
Jim Rogers
Thomas Stegen
[snip]
>
> PS. Approx. 98% of all people I know who have tried to convince me of the
> superiority of OOP ( often citing code reuse as a major part of that
> superiority ) haven't even been able to describe to me what OOP is.
Once someone starts rambling on about OOP being superior to procedural
you already have a good clue they have little clue.
> In fact,
> they haven't even been able to tell me exactly what an Object is.
This is not just not having a clue, this borders on incompetence. You
need to get to know some new people ;)
> Do we
> really want "All" programming languages to be OOP ( as has been suggested many
> times before )?? Go figure!?! ;-)
No of course not, they should be functional. This is quicksort in
Haskell (a functional language)
quicksort [] = []
quicksort (x:xs) = quicksort [y | y <- xs, y < x]
++ [x]
++ quicksort [y | y <- xs, y >= x]
;)
--
Thomas Stegen
http://www.geocities.com/thinkoidz
Chris Dutton
>> it easier to *write* reusable code.
>
> Oooooh I think we'll have to agree to disagree there. I would very
> quickly agree, however, that OO makes it easier for /some/ people to
> write reusable code.
Objects seem, to me at least, to relate better to "things" in the "real
world" than, say, functional programming concepts. Seems to make it
easier to convey OO theory without first having to teach the basics of
the language you'll use to dmonstrate those concepts later on.
Of course, this is a purely subjective observation.
Dan Tex1
>Date: 7/8/02 5:26 AM Pacific Daylight Time
>Message-id: <3D2984F1...@cis.strath.ac.uk>
>
>Dan Tex1 wrote:
>
>[snip]
>
>>
>> PS. Approx. 98% of all people I know who have tried to convince me of the
>> superiority of OOP ( often citing code reuse as a major part of that
>> superiority ) haven't even been able to describe to me what OOP is.
>
>Once someone starts rambling on about OOP being superior to procedural
>you already have a good clue they have little clue.
>
>> In fact,
>> they haven't even been able to tell me exactly what an Object is.
>
>This is not just not having a clue, this borders on incompetence. You
>need to get to know some new people ;)
Hehe.... I hear ya!!!!
My problem is... I'm an engineer, and I work mainly with other engineers.
The ones who go around expounding on the virtues of OOP really haven't
programmed that much and are really just regurgitating what they've been told.
Unfortunately,... many of them have taken ( are taking ) CSci courses at the
local Universities and just believe everything every professor tells them....
and.... most of the professors are telling them that it's OOP or nothing.
Actually... my real problem is... I sometimes have to deal with some of the
stuff these guys write. Not an easy task when a guy who doesn't actually
understand OOP is attempting to put together OOP style codes.
>> Do we
>> really want "All" programming languages to be OOP ( as has been suggested
>many
>> times before )?? Go figure!?! ;-)
>
>No of course not, they should be functional. This is quicksort in
>Haskell (a functional language)
>
>quicksort [] = []
>quicksort (x:xs) = quicksort [y | y <- xs, y < x]
> ++ [x]
> ++ quicksort [y | y <- xs, y >= x]
>
> ;)
OK. That's gotta be the most compact quicksort code I've ever seen. Is it
"ALL" there???
How does the program know what data types it is operating on? Or... does it
even matter?
Dan :-)
Richard Heathfield
>
<snip>
>
[a couple of people said...]
> >> Do we
> >> really want "All" programming languages to be OOP ( as has been suggested
> >many
> >> times before )?? Go figure!?! ;-)
> >
> >No of course not, they should be functional. This is quicksort in
> >Haskell (a functional language)
> >
> >quicksort [] = []
> >quicksort (x:xs) = quicksort [y | y <- xs, y < x]
> > ++ [x]
> > ++ quicksort [y | y <- xs, y >= x]
> >
> > ;)
>
> OK. That's gotta be the most compact quicksort code I've ever seen. Is it
> "ALL" there???
> How does the program know what data types it is operating on? Or... does it
> even matter?
I must stress I don't know Haskell, but I suspect it doesn't matter in
the slightest, for the same reason that it wouldn't matter to a C
function or a C++ function: i.e. a mechanism exists for removing the
need for that information. In C, it's the comparison function. In C++,
it's operator overloading. Heaven knows what Haskell calls it, but it'll
be something of that ilk.
Koen Witters
> Hehe.... I hear ya!!!!
> My problem is... I'm an engineer, and I work mainly with other
> engineers. The ones who go around expounding on the virtues of OOP really
> haven't programmed that much and are really just regurgitating what
> they've been told.
> Unfortunately,... many of them have taken ( are taking ) CSci courses at
> the
> local Universities and just believe everything every professor tells
> them.... and.... most of the professors are telling them that it's OOP or
> nothing.
Then they need to find better professors ;-).
Look, this is what my professor told me, and it seems to be correct:
Functional Decomposition:
pros
- Good with stable requirements
- Good with one monolithic function
=> Clear problem decomposition strategy
cons
- Systems with more than one main function
- System functions evolve -> cross-cuts whole system
- Interfacing with other systems is difficult
(how to merge 2 systems maintaining customer addresses?)
Object-Oriented Decomposition:
pros
- Better for complex and evolving systems
=> encapsulation provides robustness agains typical changes
cons
- how to find the objects?
So, as you see, there is no superiour way, it all depends on the problem.
kind regards,
deWiTTERS
Al Dunbar
"Chris Dutton" <ch...@cmb-enterprises.com> wrote in message
news:20020708215...@news.fltg.net...
Remembering the agony of the first programming course I took, I do not think
my professors /would/ have been able to teach me /concepts/ whatsoever
without first showing me the nuts and bolts, so to speak. I could barely
understand the concepts of source code, object code, and data, let alone the
more abstract concepts of which you speak (and which I now more fully
appreciate).
> Of course, this is a purely subjective observation.
How objective of you to say so ;-)
/Al
Chris Dutton
>
> Remembering the agony of the first programming course I took, I do not
> think my professors /would/ have been able to teach me /concepts/
> whatsoever without first showing me the nuts and bolts, so to speak. I
> could barely understand the concepts of source code, object code, and
> data, let alone the more abstract concepts of which you speak (and
> which I now more fully appreciate).
Well, when I go though creating, say, a Person, I start out simple. I
build the Person in a general sense. The head connects to the neck, the
neck to the body, etc., and the relationships between different
components. This, in my opinion, is where objects matter.
The details are where the procedural concepts and syntax come in. I try
never to say that object-oriented programming and procedural programming
are distinct things, because then you get in trouble later on when
someone puts two and two together and realizes "hey, isn't that 'method'
just a procedure?"
Willard Thompson
If I may add to this thread as well. OO provides inheritance (white
box reuse) and composition (black box reuse) mechanisms. An object
that uses another object can use the implementation of any of it's
children objects if needed via a common interface. Via polymorphism
and dynamic binding using an object's feature only needs to occur once
because the type has already been casted. So for a procedural
language let's say that you want to call a function say perimeter for
various shapes then you would have to traverse a set of if statements
for each shape. Where as again with OO programming just invoke
perimeter when you need to and the correct one will be called.
Another form of reuse not captured in procedural languages is
genericity (using a template in C++). Let's say that you want to have
a stack relationship for many different items. Why build a unique
stack data structure for each of those items where you can make one
generic stack structure where many other types can use.
Willard
Richard Heathfield
>
> jcar...@ecopetrol.com.co (Tortolo) wrote in message news:<26176b48.02070...@posting.google.com>...
> > How object-oriented programming allows for easier code reuse than
> > under procedural languages??
> >
> > Thanks,
> >
> > Jairo
>
> If I may add to this thread as well. OO provides inheritance (white
> box reuse) and composition (black box reuse) mechanisms. An object
> that uses another object can use the implementation of any of it's
> children objects if needed via a common interface. Via polymorphism
> and dynamic binding using an object's feature only needs to occur once
> because the type has already been casted.
So far, no complaints... ;-)
> So for a procedural
> language let's say that you want to call a function say perimeter for
> various shapes then you would have to traverse a set of if statements
> for each shape.
Not necessarily. One obvious alternative strategy is to use an array of
function pointers (or, for languages in which functions are first-class
objects, an array of the functions themselves might be more suitable).
That should be a fair bit quicker than if-ladders or switch statements.
Of course, it doesn't have to be an array; it might be a tree of some
kind (in which case you do get the ifs, but only something like log n of
them).
> Where as again with OO programming just invoke
> perimeter when you need to and the correct one will be called.
Likewise, or very close to likewise, with a sensible procedural
approach. Something like:
Perimeter = (*CalcPerimeter[MyShape.Type])(&MyShape);
> Another form of reuse not captured in procedural languages is
> genericity (using a template in C++). Let's say that you want to have
> a stack relationship for many different items. Why build a unique
> stack data structure for each of those items where you can make one
> generic stack structure where many other types can use.
Hey, guess what? I made a generic stack structure that many other types
can use, and I did it quite naturally and easily, in a *non*-OO
language. I did the same for linked lists (single and double), queues,
dequeues, circular lists, yadayadayada... It's not only possible but in
fact fairly easy to write procedural code with this kind of generality
in mind.
Code re-use is as old as code. It's certainly possible in OOP, but let's
not make the mistake of thinking that re-use is a characteristic unique
to, or even better suited to, that paradigm.
Dan Tex1
>Date: 7/10/02 9:27 AM Pacific Daylight Time
>Message-id: <303ff1c.02071...@posting.google.com>
>
>jcar...@ecopetrol.com.co (Tortolo) wrote in message
>news:<26176b48.02070...@posting.google.com>...
>> How object-oriented programming allows for easier code reuse than
>> under procedural languages??
>>
>> Thanks,
>>
>> Jairo
>
>If I may add to this thread as well. OO provides inheritance (white
>box reuse) and composition (black box reuse) mechanisms. An object
>that uses another object can use the implementation of any of it's
>children objects if needed via a common interface. Via polymorphism
>and dynamic binding using an object's feature only needs to occur once
>because the type has already been casted. So for a procedural
>language let's say that you want to call a function say perimeter for
>various shapes then you would have to traverse a set of if statements
>for each shape. Where as again with OO programming just invoke
>perimeter when you need to and the correct one will be called.
I can easily do the above in standard fortran ( procedural ). No "IF"
statements required. Fortran's way of doing such is not as flexible ( as say,
C++ ), but... nonetheless... it is quite is and very uncomplicated.
Dan :-)