Object Oriented Programming (OOP)

[Pmb]

Hi. I'm new to this group. I'm refreshing/learning C++ and am starting to
learn Object Oriented Programming (OOP). In discussing this with people I
came up short as to what the benefits of OOP are. For example: As I
understand it, OOP has its main benefit in software reuse. Thus one develops
a software library of classes and this cuts down the overhead of reinventing
the wheel. Someone might say that this can be done with structured
programming with function libraries. So I have a few questions.

1) For those of you who like OOP, why do you like it?
2) Can OOP be accomplished with non-object oriented languages such as C?
3) If you're not part of a software engineering team but are programming
from your own use and don't need to reuse code would you bother with OOP?

Thanks

Pmb

[Allan Bruce]

"Pmb" <so*****@somewhere.com> wrote in message
news:b4********************@comcast.com...

Hi. I'm new to this group. I'm refreshing/learning C++ and am starting to
learn Object Oriented Programming (OOP). In discussing this with people I
came up short as to what the benefits of OOP are. For example: As I
understand it, OOP has its main benefit in software reuse. Thus one develops a software library of classes and this cuts down the overhead of reinventing the wheel. Someone might say that this can be done with structured
programming with function libraries. So I have a few questions.

1) For those of you who like OOP, why do you like it?
It forces a better design in my opinion, and offers data hiding. Another
advantage is the reduced amount of parameters transferred to and from
functions, since many methods access member variables within a class
2) Can OOP be accomplished with non-object oriented languages such as C?
It can be emulated, but from what I have seen is very messy, and isnt
readable.
3) If you're not part of a software engineering team but are programming
from your own use and don't need to reuse code would you bother with OOP?

I program for pleasure and use it for many reasons, here is an example:

I have a game which I am programming. The entities in my game follow a
simple heirarchy:

class GameEntity // specifies interface for Step() and Draw(). Has one
member variable "bool Valid"

class Ship : public GameEntity // define a ship which has Shoot(), Die()
etc.

class PlayerShip : publilc Ship // defines the player ship which has input
controls etc.

I follow a similar heirarchy for scenery, for powerups etc. It makes things
a lot neater, and if you incorporate the methods as high up the hierarchy as
possible, the less duplicate code there is.

Allan

[nevyn]

Hi, this will be my first post to this group as well...

I've only just started using OOP myself. It's kind of interesting the sort
of mind set you get into. Although I still believe that alot of OOP
implementation is done just plain badly it does make it easier to relate
your code to real 'objects'.

Personally I think both have their place but OOP allows you encapsulate
things a hell of alot better than just straight stuctured.

C doesn't allow for the encapsulation that OOP pushes and so is unsuitable
for OOP - but if you aren't one for the rules and want to make things a
hell of alot harder on yourself, seeing as OOP seems to be a mentality
more than anything, C and possibly even pascal should be able to do it to
some strange and wierd extent.

If programming for your own use, I still think OOP is worthwhile. If at
some later date you wish you go over the code again, it's alot easier
looking at the individual objects and knowing exactly what they relate to
rather than trying to figure out each of the functions. This could of
course be fixed with comments but why bother if you can just code it in?

From working with a friend on the occassional little project, I've found
that we can each work on an object each, pull them together and get it all
working together with very little work involved.

Hope this at least answers some of your questions...

regards, Nevyn.

On Fri, 21 May 2004 07:53:08 -0400, Pmb wrote:

Hi. I'm new to this group. I'm refreshing/learning C++ and am starting to
learn Object Oriented Programming (OOP). In discussing this with people I
came up short as to what the benefits of OOP are. For example: As I
understand it, OOP has its main benefit in software reuse. Thus one develops
a software library of classes and this cuts down the overhead of reinventing
the wheel. Someone might say that this can be done with structured
programming with function libraries. So I have a few questions.

1) For those of you who like OOP, why do you like it?
2) Can OOP be accomplished with non-object oriented languages such as C?
3) If you're not part of a software engineering team but are programming
from your own use and don't need to reuse code would you bother with OOP?

Thanks

Pmb

[Pmb]

<ne***@localhost.localdomain> wrote in message
news:pa****************************@localhost.loca ldomain...

Hi, this will be my first post to this group as well...

I've only just started using OOP myself. It's kind of interesting the sort
of mind set you get into. Although I still believe that alot of OOP
implementation is done just plain badly it does make it easier to relate
your code to real 'objects'.

Personally I think both have their place but OOP allows you encapsulate
things a hell of alot better than just straight stuctured.

C doesn't allow for the encapsulation that OOP pushes and so is unsuitable
for OOP - but if you aren't one for the rules and want to make things a
hell of alot harder on yourself, seeing as OOP seems to be a mentality
more than anything, C and possibly even pascal should be able to do it to
some strange and wierd extent.

If programming for your own use, I still think OOP is worthwhile. If at
some later date you wish you go over the code again, it's alot easier
looking at the individual objects and knowing exactly what they relate to
rather than trying to figure out each of the functions. This could of
course be fixed with comments but why bother if you can just code it in?

From working with a friend on the occassional little project, I've found
that we can each work on an object each, pull them together and get it all
working together with very little work involved.

Hope this at least answers some of your questions...

Yes. Thanks.

Would you use OOP if you were writing a program to do some number crunching,
e.g. solving a differential equation etc.?

Pmb

[Pmb]

"Allan Bruce" <al*****@TAKEAWAYf2s.com> wrote in message
news:c8**********@news.freedom2surf.net...

"Pmb" <so*****@somewhere.com> wrote in message
news:b4********************@comcast.com...

Hi. I'm new to this group. I'm refreshing/learning C++ and am starting to learn Object Oriented Programming (OOP). In discussing this with people I came up short as to what the benefits of OOP are. For example: As I
understand it, OOP has its main benefit in software reuse. Thus one develops

a software library of classes and this cuts down the overhead of

reinventing

the wheel. Someone might say that this can be done with structured
programming with function libraries. So I have a few questions.

1) For those of you who like OOP, why do you like it?

It forces a better design in my opinion, and offers data hiding. Another
advantage is the reduced amount of parameters transferred to and from
functions, since many methods access member variables within a class

2) Can OOP be accomplished with non-object oriented languages such as C?

It can be emulated, but from what I have seen is very messy, and isnt
readable.

3) If you're not part of a software engineering team but are programming
from your own use and don't need to reuse code would you bother with OOP?

I program for pleasure and use it for many reasons, here is an example:

I have a game which I am programming. The entities in my game follow a
simple heirarchy:

class GameEntity // specifies interface for Step() and Draw(). Has one
member variable "bool Valid"

class Ship : public GameEntity // define a ship which has Shoot(), Die()
etc.

class PlayerShip : publilc Ship // defines the player ship which has input
controls etc.

I follow a similar heirarchy for scenery, for powerups etc. It makes

things a lot neater, and if you incorporate the methods as high up the hierarchy as possible, the less duplicate code there is.

Thanks.

As I asked Nevyn, would you use OOP if you were writing a program to do some
number crunching, e.g. solving a differential equation etc.?

Pmb

[Allan Bruce]

> Thanks.

As I asked Nevyn, would you use OOP if you were writing a program to do some number crunching, e.g. solving a differential equation etc.?

Pmb

It entirely depends!

I would use OOP if it were part of a bigger project, no two ways about it.
For example, one class may be a solver for differenial equations. One could
have linear ODEs and others done within this class.

If you mean, would I program an OOP just to solve one equation, then the
answer is no. I would do it in Matlab!

Basically, what I am trying to say is, if I am programming something of
medium scale or larger, then I would do it using OOP, if it is small scale,
i.e. a few lines of code, then I wouldn't program it in a low-level
language, I would use other tools, e.g. Matalab.

Allan

[bartek]

"Pmb" <so*****@somewhere.com> wrote in
news:V8********************@comcast.com:

(...)

Would you use OOP if you were writing a program to do some number
crunching, e.g. solving a differential equation etc.?

Why not? http://www.oonumerics.org/

"Object oriented" describes a programming paradigm. As all other paradigms,
you can see it in different perspectives, depending on your own point of
view.

C++ being a multi-paradigm language, allows you to freely mix OO concepts
with plain imperative 'C' programming style, and even functional style.
On one hand, it's much more versatile and powerful. On the other, it gives
*a lot* of opportunities for misuse. This is all obvious, though. :)

--
:: bartekd [at] o2 [dot] pl

[Shashank]

Hi Pmb,

I like component programming in C++. I also like programming OOP. Simply because
it allows you to comprehend the problems/ solution in terms of objects rather
then functions. It just allows you to structure your program better then what is
possible using even C but in a easier way.

Encapsulation, polymorphism, inheritance are features are OOAD and can be
achieved using C as well, but yeah simple to achieve or design in C++.

Similarly re-use or not you may do in C as well as C++. Its just because you can
comprehend the problem and solution easier in OO methodology that enhances
chances of writing code that may be re-used.

So you will find, moving from C to C++ (or object oriented) is primarily because
it allows to create well structured software easily (because of some features as
mentioned above, that are by default part of objects then in structure where
you will have to code for it!!) compared to structure language.

regards,
Shashank

Pmb wrote:

Hi. I'm new to this group. I'm refreshing/learning C++ and am starting to
learn Object Oriented Programming (OOP). In discussing this with people I
came up short as to what the benefits of OOP are. For example: As I
understand it, OOP has its main benefit in software reuse. Thus one develops
a software library of classes and this cuts down the overhead of reinventing
the wheel. Someone might say that this can be done with structured
programming with function libraries. So I have a few questions.

1) For those of you who like OOP, why do you like it?
2) Can OOP be accomplished with non-object oriented languages such as C?
3) If you're not part of a software engineering team but are programming
from your own use and don't need to reuse code would you bother with OOP?

Thanks

Pmb

[Jeff Relf]

Hi Pmb, a.k.a. Pete,

In an e-mail, you asked me why I think OOP is modal.

Google, " define:modal ":
http://www.google.com/search?q=defin...al&btnG=Search
" Pertaining to modes. "
...
" A dialog is modal if its parent application
is blocked from further activity
^^^^^^^
until the dialog has completed. See non-modal. "

OOP is a hierarchy,
and, like all hierarchies, it's usually overdone.

The flatter one can keep one's data
the more accessible it becomes.

For example, take a perfectly flat map of the world,
a user simply pans and zooms to see what he wants.
No need to go browsing through
some absurd tree of rigid directories,
branching here and there, going ever deeper,
getting ever more lost.

That's the problem with OOP, it's too convoluted.

I hate pop-ups for the same reason,
as each dialog window pops up, you enter another mode,
it's annoying. Flat is where it's at.

In my programs I make a real effort to
eliminate All pop-ups.
I also don't like sub-sub-sub-sub menus.

So I replace them with a maximized window
( where my Win98 taskbar is the only other window ).

Then I navigate using different combinations and durations
of buttons on my 5 button wheel mouse ...
So that everything is accessible all the time,
no need to consider what mode I might be in.

The terrain ( i.e. the data ) is keep flat like a map ...
I just pan and zoom.

[Claudio Puviani]

"Pmb" <so*****@somewhere.com> wrote

Hi. I'm new to this group. I'm refreshing/learning C++ and am starting to
learn Object Oriented Programming (OOP). In discussing this with people I
came up short as to what the benefits of OOP are. For example: As I
understand it, OOP has its main benefit in software reuse. Thus one develops
a software library of classes and this cuts down the overhead of reinventing
the wheel. Someone might say that this can be done with structured
programming with function libraries. So I have a few questions.

1) For those of you who like OOP, why do you like it?
Managing complexity is a cornerstone of programming and OOP is one tool that
helps do that. C++ offers other paradigms, including structured and generic
programming, that also help in managing complexity.
2) Can OOP be accomplished with non-object oriented languages
such as C?
Yes it can. It's just less automated. In the same vein, you can do functional,
declarative, and symbolic programming with C++. The language just doesn't give
you shortcuts to do so.
3) If you're not part of a software engineering team but are
programming from your own use and don't need to reuse
code would you bother with OOP?

If you're not a professional carpenter, but you have to put in a screw, will you
use a hammer just because it's only for your personal use? Of course not. You use
the tool that's most appropriate to what you're doing. You use OOP if the
solution can be best expressed in an OO manner. If it can best be expressed
otherwise, you don't use OOP.

Claudio Puviani

[tom_usenet]

On Fri, 21 May 2004 07:53:08 -0400, "Pmb" <so*****@somewhere.com>
wrote:

Hi. I'm new to this group. I'm refreshing/learning C++ and am starting to
learn Object Oriented Programming (OOP). In discussing this with people I
came up short as to what the benefits of OOP are. For example: As I
understand it, OOP has its main benefit in software reuse. Thus one develops
a software library of classes and this cuts down the overhead of reinventing
the wheel. Someone might say that this can be done with structured
programming with function libraries. So I have a few questions.

1) For those of you who like OOP, why do you like it?
It makes it much easier to modify behaviour in large projects (and to
think about what should be modifiable), and also gives a reasonable
way of structuring such projects.
2) Can OOP be accomplished with non-object oriented languages such as C?
Yes, but the syntax is a mess.
3) If you're not part of a software engineering team but are programming
from your own use and don't need to reuse code would you bother with OOP?

For small projects I sometimes use "object based" programming, using
classes to divide the program into modules. Many small projects (as in
just a few thousand LOC) have little scope to use polymorphism
themselves, but even then I'll usually use OOP libraries at some
point. Any time you write "std::cout" you are using OOP...

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[Pmb]

"Allan Bruce" <al*****@TAKEAWAYf2s.com> wrote in message
news:c8**********@news.freedom2surf.net...

Thanks.

As I asked Nevyn, would you use OOP if you were writing a program to do some

number crunching, e.g. solving a differential equation etc.?

Pmb

It entirely depends!

I would use OOP if it were part of a bigger project, no two ways about it.
For example, one class may be a solver for differenial equations. One

could have linear ODEs and others done within this class.

If you mean, would I program an OOP just to solve one equation, then the
answer is no. I would do it in Matlab!
No. I'm thinking more or less number crunching with C++. E.g. suppose you
were tasked with creating a library function for the confluent
hypergeometric function of the first kind, or something as equally
obnoxious. :-)

One can't always turn to Mathlab, especially if you don't have it.

Basically, what I am trying to say is, if I am programming something of
medium scale or larger, then I would do it using OOP, if it is small scale, i.e. a few lines of code, then I wouldn't program it in a low-level
language, I would use other tools, e.g. Matalab.

and if you were someone like me who didn't have Matlab?

Thanks

Pmb

[G. Morgen]

I suggest another name: OOPS
Object Oriented Ploughramming Swine

[Allan Bruce]

"Pmb" <so*****@somewhere.com> wrote in message
news:8e********************@comcast.com...

"Allan Bruce" <al*****@TAKEAWAYf2s.com> wrote in message
news:c8**********@news.freedom2surf.net...

Thanks.

As I asked Nevyn, would you use OOP if you were writing a program to

do some

number crunching, e.g. solving a differential equation etc.?

Pmb

It entirely depends!

I would use OOP if it were part of a bigger project, no two ways about it. For example, one class may be a solver for differenial equations. One

could

have linear ODEs and others done within this class.

If you mean, would I program an OOP just to solve one equation, then the
answer is no. I would do it in Matlab!

No. I'm thinking more or less number crunching with C++. E.g. suppose you
were tasked with creating a library function for the confluent
hypergeometric function of the first kind, or something as equally
obnoxious. :-)

One can't always turn to Mathlab, especially if you don't have it.

Basically, what I am trying to say is, if I am programming something of
medium scale or larger, then I would do it using OOP, if it is small

scale,

i.e. a few lines of code, then I wouldn't program it in a low-level
language, I would use other tools, e.g. Matalab.

and if you were someone like me who didn't have Matlab?

Thanks

Pmb

I think what you are trying to get at, is, OOP is slower for number
crunching. If so, then this is rubbish. Why would it be slower? OOP is
just as fast as any other programming paradigm for number crunching. If
this is not what you are trying to get at, then perhaps rephrasing your
question is needed?

OOP is about design, number crunching is an implementation within a design.
Cant say much more without clarification of what you want to know...

Allan

[G. Morgen]

> I suggest another name: OOPS

Object Oriented Ploughramming Swine

Progscriptum: No personal offence meant

[Derek]

Pmb wrote:

Hi. I'm new to this group. I'm refreshing/learning C++
and am starting to learn Object Oriented Programming
(OOP). In discussing this with people I came up short
as to what the benefits of OOP are. For example: As I
understand it, OOP has its main benefit in software
reuse. Thus one develops a software library of classes
and this cuts down the overhead of reinventing the
wheel. Someone might say that this can be done with
structured programming with function libraries. So I have
a few questions.

1) For those of you who like OOP, why do you like it?
The big three reasons to use it (encapsulation,
inheritance, polymorphism) help me structure code in a
well-defined, maintainable, and (usually) reusable way.
2) Can OOP be accomplished with non-object oriented
languages such as C?
Absolutely, but it's not pretty. There are whole C
libraries that are OO by convention, but it's not a pretty
sight. If you want OOP, it's best to use a language that
supports it directly.
3) If you're not part of a software engineering team but
are programming from your own use and don't need to reuse
code would you bother with OOP?

See #1. Even if I don't plan to reuse code, OOP helps me
organize problems in a well-defined, maintainable form.
This has value even if I'm the only customer, so to speak.
Also remember that C++ is a multi-paradigm language:
it support OOP, but doesn't require it. If structured
programming makes more sense than OOP for a part of your
problem, then C++ lets you mix SP and OOP freely. That's a
big reason it's so powerful.

[Pmb]

"Allan Bruce" <al*****@TAKEAWAYf2s.com> wrote

I think what you are trying to get at, is, OOP is slower for number
crunching. If so, then this is rubbish. Why would it be slower? OOP is
just as fast as any other programming paradigm for number crunching. If
this is not what you are trying to get at, then perhaps rephrasing your
question is needed?

That wasn't what I was getting to. I was wondering if some problems more
readily lend themselves to structured programming in that they are easier to
write etc. Speed was not what I had in mind. OOP works best when you're
modeling real world objects right? What about abstract things for which
there may be no real world thing which to model.? Area under a curve etc.
Perhaps math wasn't the best example to use but it was what came to mind.
I'll have better questions as I learn.

Pmb

[Pmb]

"Derek" <us**@nospam.org> wrote

If structured
programming makes more sense..

That's what I'm thinking. Do you know of a way to describe in general when
to use OOP rather than structured programming? I.e. are some types of tasks
better left to structured programming?

Thanks

Pmb

[osmium]

Claudio Puviani writes:

3) If you're not part of a software engineering team but are
programming from your own use and don't need to reuse
code would you bother with OOP?
If you're not a professional carpenter, but you have to put in a screw,

will you use a hammer just because it's only for your personal use? Of course not. You use the tool that's most appropriate to what you're doing. You use OOP if the
solution can be best expressed in an OO manner. If it can best be expressed otherwise, you don't use OOP.

As I understood the OPs question, and if you wish to use analogies, ISTM a
more appropriate analogy would be "Would you build a skyscraper out of
wood?"

People working alone produce small programs. A group of a 100 or so
programmers face a new set of problems.

I have been thinking of posting a longer message to this thread if I get
around to it, but for now I would say that if a problem has a lot of
"state", it is probably time to use OOP. Continuing the C vs. C++ base, (as
opposed to a generic OOP base): if you find yourself using more than a very
few static variables, I think you've got an OOP problem on your hands.

[Allan Bruce]

"Pmb" <so*****@somewhere.com> wrote in message
news:I9********************@comcast.com...

"Allan Bruce" <al*****@TAKEAWAYf2s.com> wrote

I think what you are trying to get at, is, OOP is slower for number
crunching. If so, then this is rubbish. Why would it be slower? OOP is just as fast as any other programming paradigm for number crunching. If
this is not what you are trying to get at, then perhaps rephrasing your
question is needed?
That wasn't what I was getting to. I was wondering if some problems more
readily lend themselves to structured programming in that they are easier

to write etc. Speed was not what I had in mind. OOP works best when you're
modeling real world objects right? What about abstract things for which
there may be no real world thing which to model.? Area under a curve etc.
Perhaps math wasn't the best example to use but it was what came to mind.
I'll have better questions as I learn.

Pmb

Ok, I understand now. There are definately some examples that are obvious to
be implemented in OOP. Other problems may not be as obvious, for example
your maths example. Here, there are no 'objects' as such, but this is when
I use OOP for modules. For example, I would create a class for my Maths
Module, and one for my GUI.. This isnt OOP as such, but you can still
benefit from the advantages of OOP.
Allan

[Dave Vandervies]

In article <b4********************@comcast.com>,
Pmb <so*****@somewhere.com> wrote:

Hi. I'm new to this group. I'm refreshing/learning C++ and am starting to
learn Object Oriented Programming (OOP). In discussing this with people I
came up short as to what the benefits of OOP are. For example: As I
understand it, OOP has its main benefit in software reuse. Thus one develops
a software library of classes and this cuts down the overhead of reinventing
the wheel. Someone might say that this can be done with structured
programming with function libraries. So I have a few questions.

1) For those of you who like OOP, why do you like it?
Because it makes some problems a lot easier to deal with.

In particular, being able to hide the details of how something works
behind a well-defined interface can make it a lot easier to localize the
complexity in a program. (There is, however, a lot more room to make
something go Very Wrong in designing the interfaces than in building
the code that uses the interfaces, so using OO for encapsulation without
paying attention to getting the interfaces right is asking for trouble.)

Besides the encapsulation benefits (which, with a little bit more
discipline, can be had without OO), there are also places where the
polymorphism made possible by the OO model leads to a cleaner solution
than other ways of looking at things would lead to. (F'rexample, any
problem whose solution involves dealing with objects that have different
behaviors but have the same interface and can be sensibly used in the
same places.)

2) Can OOP be accomplished with non-object oriented languages such as C?
Yes. I don't find it as ugly as a lot of people do, but there are a
lot of details you need to keep track of yourself and therefore a lot
of room to introduce errors. If you find yourself wanting to do OOP in
a non-OO language, it's probably time to reconsider either your choice
of tools or your approach.

3) If you're not part of a software engineering team but are programming
from your own use and don't need to reuse code would you bother with OOP?

If it's the right tool for the job.
It won't solve all the world's problems, but there are a lot of classes
of problem where the interface-centric, implementation-agnostic model
makes the solution a lot cleaner (or even makes a solution possible).
If you *really* want to understand OO, I would suggest learning both
an OO language with strong static type-checking (such as C++) and an OO
language where an object's "type" is dynamically determined entirely by
its interface (such as Smalltalk). (`Learning' here means wrapping your
brain around the mindset the language needs to be used effectively, not
just figuring out where the semicolons go.) Be warned that this is not
a trivial undertaking, but seeing (and understanding) the similarities
and differences between the two variants of "object-oriented" programming
languages is Rather Helpful.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
Between invoking undefined behaviour by calling it without a prototype in
scope and doing it by including a non-standard header, I chose the latter.
--Dan Pop in comp.lang.c

[Derek]

> > If structured programming makes more sense..

That's what I'm thinking. Do you know of a way to
describe in general when to use OOP rather than
structured programming? I.e. are some types of tasks
better left to structured programming?

That's not an easy question to answer. The answer depends
on the programmer's background, the nature of the problem,
as well as external constraints (eg, what your boss wants).

As an OO/C++ programmer, I have a natural bias toward
decomposing a problem in terms of objects and operations.
Especially if it appears that a "natural" solution might
involve inheritance or polymorphism.

However, if all I need is a collection of utility
functions, that's what I write. I don't try to invent
objects where none logically exist.

I wish I had a simpler, more concrete answer to your
question, but as with most interesting questions, the
answer is "is depends."

[Dave Vandervies]

In article <n6********************@comcast.com>,
Pmb <so*****@somewhere.com> wrote:

"Derek" <us**@nospam.org> wrote

If structured
programming makes more sense..

That's what I'm thinking. Do you know of a way to describe in general when
to use OOP rather than structured programming? I.e. are some types of tasks
better left to structured programming?

Understand both models, including their benefits and limitations.
Understand the tools you're working with, including which models they
make easier and harder to deal with.

Based on that understanding, consider which model will lead to a cleaner,
easier to understand solution to the problem at hand.
This is Not An Easy Problem. Expect to end up in the middle of solving
something realizing that a different approach would have worked better.
Don't be afraid to try multiple solutions to the same problem to see
how well they fit. Expect to spend a lot of time and energy and make
a lot of mistakes before you're good at it (or even reasonably competent).
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
Between invoking undefined behaviour by calling it without a prototype in
scope and doing it by including a non-standard header, I chose the latter.
--Dan Pop in comp.lang.c

[Derek]

> That wasn't what I was getting to. I was wondering if

some problems more readily lend themselves to structured
programming in that they are easier to write etc. Speed
was not what I had in mind. OOP works best when you're
modeling real world objects right? What about abstract
things for which there may be no real world thing which
to model.? Area under a curve etc. Perhaps math wasn't
the best example to use but it was what came to mind.
I'll have better questions as I learn.

OOP works well when you are modeling concepts that map well
to objects, which are not necessarily "real world" objects.
For example, there are lots of OO numerical libraries at

http://www.oonumerics.org/oon/

You will find lots of examples of abstract mathematical
concepts that map very well to objects, as well as many
that don't but still benefit from OO techniques indirectly.

For example, many algorithms in the Blitz++ numerical
library aren't stricly OO, but the containers that store the
data that they operate on are objects:

http://www.oonumerics.org/blitz/

So convolution, for example, might be a garden variety
(template) function, but a uniform random number generator
is a class, as is a vector of input data. The cool thing
about C++ is that OO and non-OO can happily coexist.

[Thomas Matthews]

Pmb wrote:

Hi. I'm new to this group. I'm refreshing/learning C++ and am starting to
learn Object Oriented Programming (OOP). In discussing this with people I
came up short as to what the benefits of OOP are. For example: As I
understand it, OOP has its main benefit in software reuse. Thus one develops
a software library of classes and this cuts down the overhead of reinventing
the wheel. Someone might say that this can be done with structured
programming with function libraries. So I have a few questions.
Code reuse can be accomplished with many paradigms, not just OOP.
OOP is more about organizing data with methods (functions) than
as a way to develop reusable software. There are many utility
functions that can be reused, but don't fit into the OOP paradigm.

I prefer to generate reusable code through evolution or factoring.
Trying to predict what will be reused or what can be reused is
kind of like premature optimization.

1) For those of you who like OOP, why do you like it?
I like the OOP because it models hardware components quite nicely.
A platform can have 2 instances of a UART component, which sounds
just like having 2 instances of a UART class.

Unfortunately, I haven't come across a 100% OOP project yet. Most of
the projects are either procedural driven or a combination of OOP and
procedural. Some of the systems may have many objects, but there isn't
any justification to have one object to rule them all; but there could
be one function to bind them all.

2) Can OOP be accomplished with non-object oriented languages such as C?
As others have stated, yes and it is messy. However, combining OOP and
procedural isn't as messy as pure OOP.

3) If you're not part of a software engineering team but are programming
from your own use and don't need to reuse code would you bother with OOP?
On my own projects, I use OOP if the need arises. Some applications are
modelled nicely with OOP. However, some smaller applications are
developed faster and easier using procedural methods.


Thanks

Pmb

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

[Mike Wahler]

"Pmb" <so*****@somewhere.com> wrote in message
news:b4********************@comcast.com...

Hi. I'm new to this group. I'm refreshing/learning C++ and am starting to
learn Object Oriented Programming (OOP). In discussing this with people I
came up short as to what the benefits of OOP are. For example: As I
understand it, OOP has its main benefit in software reuse.
IMO that's one 'side' benefit, but not the 'main' one.
I think the 'main' one is the ability to express a
solution more directly in terms of the problem domain.
Thus one develops
a software library of classes and this cuts down the overhead of reinventing the wheel. Someone might say that this can be done with structured
programming with function libraries.
Yes, it can. "Reusability" isn't really a concept specific to OOP.
So I have a few questions.

1) For those of you who like OOP, why do you like it?
See above. IMO the ability to more directly model a
problem/solution translates to better productivity,
as well as maintainability (via more expressive, and
hopefully more readable, code).
2) Can OOP be accomplished with non-object oriented languages such as C?
Certainly, although it often entails more complexity (thus
effort) than with languages which are more OO 'by nature'.
Right Tool For The Job, and all that.
3) If you're not part of a software engineering team but are programming
from your own use and don't need to reuse code would you bother with OOP?

Yes, but I'll qualify that with "it depends upon the application".

-Mike

[Dave Townsend]

> That wasn't what I was getting to. I was wondering if some problems more

readily lend themselves to structured programming in that they are easier to write etc. Speed was not what I had in mind. OOP works best when you're
modeling real world objects right? What about abstract things for which
there may be no real world thing which to model.? Area under a curve etc.
Perhaps math wasn't the best example to use but it was what came to mind.
I'll have better questions as I learn.
Surely objects model abstract things much better , real world objects
are very hard to model in general, like how do you model a person ?
Generally, we only model some important aspects of a real world object,
that is an abstraction, a person for instance is a lot more complex than a
SSN, a name
age and place of birth!
Also, C++ and C are like Lego and Duplo, they can be combined together to
take advantage of the strengths of object oriented and procedural approaches
so you can have it both ways, unlike Java which forces you into an object
oriented
approach for everything.

In the original post, C++ can be equally good at number crunching as C, in
fact better
in some respects because the objects/interfaces can be designed to be more
aligned with the
mathematical operations and objects they represent. For instance, multiple
dimension arrays/matrices
can work with the syntax you'd expect, rather than the contrived interfaces
I've seen with C.
Similarly, you can do multiple/arbitrary precision arithmetic with the same
ease as regular arithmetic
in C++, but is very messy and unreadable in C. I believe that the STL has
been designed and
implemented in order that certain numerical operations on vectors can be
performed as efficiently as equivalent Fortran arrays.

There's a good bunch of C code out there for number crunching already, so C
has an edge there in that respect, but its not because C is a better
language. There's even more Fortran numerical stuff out
there too!

"Pmb" <so*****@somewhere.com> wrote in message
news:I9********************@comcast.com...
"Allan Bruce" <al*****@TAKEAWAYf2s.com> wrote

I think what you are trying to get at, is, OOP is slower for number
crunching. If so, then this is rubbish. Why would it be slower? OOP is just as fast as any other programming paradigm for number crunching. If
this is not what you are trying to get at, then perhaps rephrasing your
question is needed?
That wasn't what I was getting to. I was wondering if some problems more
readily lend themselves to structured programming in that they are easier

to write etc. Speed was not what I had in mind. OOP works best when you're
modeling real world objects right? What about abstract things for which
there may be no real world thing which to model.? Area under a curve etc.
Perhaps math wasn't the best example to use but it was what came to mind.
I'll have better questions as I learn.

Pmb

[Claudio Puviani]

"Dave Townsend" <da********@comcast.net> wrote

Surely objects model abstract things much better , real world
objects are very hard to model in general, like how do you
model a person ? Generally, we only model some important
aspects of a real world object, that is an abstraction, a person
for instance is a lot more complex than a SSN, a name age
and place of birth!

I agree with you regarding the fact that what we model is concepts, but we should
also keep in mind that what we call "real objects" are also only models of
concepts. There is really no intrinsic distinction between "real" objects and
software objects other than the context and the amount of detail that we put in
the model.

And to Foucault, I say, "Yes, damn you, it IS a pipe!" ;-)

Claudio Puviani

[Pmb]

"Jeff Relf" <[e-mail]> wrote in message
news:1l***************@x.Jeff.Relf...

Hi Pmb, a.k.a. Pete,

In an e-mail, you asked me why I think OOP is modal.

Google, " define:modal ":
http://www.google.com/search?q=defin...al&btnG=Search
" Pertaining to modes. "
That's what I thought you meant. However, from what I know of OOP, that
comment made no sense to me.
" A dialog is modal if its parent application
is blocked from further activity
^^^^^^^
until the dialog has completed. See non-modal. "

OOP is a hierarchy,
and, like all hierarchies, it's usually overdone.

The flatter one can keep one's data
the more accessible it becomes.

For example, take a perfectly flat map of the world,
a user simply pans and zooms to see what he wants.
No need to go browsing through
some absurd tree of rigid directories,
branching here and there, going ever deeper,
getting ever more lost.

That's the problem with OOP, it's too convoluted.

I hate pop-ups for the same reason,
as each dialog window pops up, you enter another mode,
it's annoying. Flat is where it's at.

In my programs I make a real effort to
eliminate All pop-ups.
I also don't like sub-sub-sub-sub menus.

So I replace them with a maximized window
( where my Win98 taskbar is the only other window ).

Then I navigate using different combinations and durations
of buttons on my 5 button wheel mouse ...
So that everything is accessible all the time,
no need to consider what mode I might be in.

The terrain ( i.e. the data ) is keep flat like a map ...
I just pan and zoom.

Sorry Jeff. I don't understand anything you said above in that I don't get
your analogy. Nothing of what you said sees to me to pertain to OOP. It
seems more related to the function of a particular program and not to the
design and/or implementation of the program. The later is where OOP comes
in. If you write a program then when you run it, if it runs correctly, it
would be impossible to determine if the program is and OOP.

To OOP Gurus - Please correct me if that is wrong.

Thanks

Pmb

[Jeff Relf]

Hi Pmb, a.k.a. Pete,

Re: My suggestion that OOP is often too modal,
too hierarchical, too deep.

You commented,
" Nothing of what you said sees to me to pertain to OOP.
It seems more related to
the function of a particular program
and not to the design and/or implementation of the program.
The later is where OOP comes in. "

I'm always worried about how to browse data.
To me that is the " design and/or implementation ".

Nesting modules and encapsulating stuff
just isn't an issue, if you ask me.

I can't even do serious programming
if my computer is turned on.
All the design is done exclusively in my mind.

Actually typing out the code is trivial to me.

Debugging is another story though,
that often involves lots of Google searches
and experimenting with the results in a debugger.

[Pmb]

"Jeff Relf" <[e-mail]> wrote in message
news:6g***************@x.Jeff.Relf...

Hi Pmb, a.k.a. Pete,

Re: My suggestion that OOP is often too modal,
too hierarchical, too deep.

You commented,
" Nothing of what you said sees to me to pertain to OOP.
It seems more related to
the function of a particular program
and not to the design and/or implementation of the program.
The later is where OOP comes in. "

I'm always worried about how to browse data.
To me that is the " design and/or implementation ".

Nesting modules and encapsulating stuff
just isn't an issue, if you ask me.
What do you mean by "isn't an issue"? Do you mean that it is uneccesary? If
so then consider that the OOP paradigm is not about what is neccesary.

I can't even do serious programming
if my computer is turned on.
All the design is done exclusively in my mind.
Recall that I said that OOP finds use in software engineering, not simply in
programing. If you're on a software engineering team and the programs total
millions of lines of code then you simply can't do that in your head. The
code must be read, understood and maintained by many people.

As an example, consider the project I was on in the early to mid 90's. It
was the Data Link Processor, Build II (DLP-2). This was a project to build a
system for the FAA for the up and downloading of all sorts of data
including weather data, pilot reports (PIREP), notices to airmen (NOTAM),
etc. There were several mainframes all over the country which were involved
in this system and they all had to speak to each other. The contract for
this was given to Computer Sciences Corporation and my old company Arcon
Corporation. These companies were seperated geographically, one in Waltham
MA and the other in NJ somewhere. The software team in NJ consisted of about
30 people and the one in Waltham had about 15 people. It took a few years
complete the systems analysis, a few years to go through the design phase
and a few years for coding and testing. That is not something that can be
done in one persons head and it has to be reviewed and understood by many
many people. I suspect this was a good place to employ OOD and OOP. But it
could (and perhaps was) done with structured programming.


Actually typing out the code is trivial to me.

Debugging is another story though,
that often involves lots of Google searches
and experimenting with the results in a debugger.

Nobody uses OOP because a program can't be done with structured programming.

Pmb

[Pmb]

"Dave Townsend" <da********@comcast.net> wrote in message
news:uK********************@comcast.com...

That wasn't what I was getting to. I was wondering if some problems more
readily lend themselves to structured programming in that they are easier

to

write etc. Speed was not what I had in mind. OOP works best when you're
modeling real world objects right? What about abstract things for which
there may be no real world thing which to model.? Area under a curve

etc. Perhaps math wasn't the best example to use but it was what came to mind. I'll have better questions as I learn.

Surely objects model abstract things much better , real world objects
are very hard to model in general, like how do you model a person ?

From a very very very layman's point of view - In the context of OOP I'd say
that you only model the behaviour and attributes that you need to for the
specific application.

However that is just a wild guess since I'm at the very beginning of
learning OOP.
There's a good bunch of C code out there for number crunching already, so C has an edge there in that respect, but its not because C is a better
language. There's even more Fortran numerical stuff out
there too!

I actually was trying to make a point that one might be tasked to design a
program. I'm looking to understand where OOP is useful and where its less
useful. Seems to me one is better off, in general, not using it when doing
number crunching etc. For example: At the present time I can't even fathom
how I'd do an FFT with OOP (but its been 14 years since I'd done that so
take this with a grain of salt). I can, however, see how to do signal
processing with OOP. My point being that if I'm a software engineer I can't
simply use MatLab all the time for number crunching. Especially if my job is
to work on the project for creating a new version of Matlab! :-)

Pmb

[Jeff Relf]

Hi Pmb, a.k.a. Pete,

I wrote,
" Nesting modules and encapsulating stuff
just isn't an issue, if you ask me. "

To which you replied,
' What do you mean by " isn't an issue " ?
Do you mean that it is unnecessary ?
If so then consider that the OOP paradigm is
not about what is necessary. '

I mean that encapsulation is way Way down on my list.
Other things concern me much more.

As for working in teams,
I only work with my Subject Matter Expert.
i.e. Only one other guy might me touching my source code.
and even that happens very rarely.

But when it does, I use my file comparison routine,
Dif.EXE ( at http://www.NCPlus.NET/~jeff_relf/ )
to see where he made his changes.

Larger teams would use CVS,
which keeps a copy of all changes,
allowing anyone to compare those files
using something similar to my Dif.EXE .

I'd imagine that OOP does shine quite a bit when
working with teams of people.
But, as I said, I don't have to worry about that.
( Thank God )

[Claudio Puviani]

"Pmb" <so*****@somewhere.com> wrote

At the present time I can't even fathom how I'd do
an FFT with OOP (but its been 14 years since I'd
done that so take this with a grain of salt). I can,
however, see how to do signal processing with
OOP. My point being that if I'm a software engineer
I can't simply use MatLab all the time for number
crunching. Especially if my job is to work on the
project for creating a new version of Matlab! :-)

Maybe you're having a hard time visualizing it because you're expecting to see
every aspect of the solution as OO. It will probably seem more natural if you
only consider the pieces that are a good fit for OOP. You'd probably expect to
have classes along the lines of Rational, Complex, Quaternion, Matrix, Vector,
etc. depending on the problem being solved. Right from the starting line, there's
a fairly hefty chunk of OOP. If you're planning on making the code more generic
or adaptable at runtime, you might have classes that represent niladic (no
operands), monadic (or unary), dyadic (or binary), or generalized functions. This
would allow you to create "recipes" that can be applied to a set of inputs with a
minimum of overhead. This technique in particular is entirely OOPy. You might
have support classes that implement serialization/deserialization, persistance,
etc. Your final algorithm might well be expressed procedurally, but it can still
benefit from its building blocks being OO.

Claudio Puviani

[beliavsky]

Les Hatton published a paper in 1998 finding that it is more difficult
to fix bugs in OO software. You can get it from
http://www.leshatton.org/IEEE_Soft_98a.html .

Does OO sync with the way we think ?
IEEE Software, 15(3), p.46-54
This paper argues from real data that OO based systems written
in C++ appear to increase the cost of fixing defects significantly
when compared with systems written in either C or Pascal. It goes
on to suggest that at least some aspects of OO, for example
inheritance, do not fit well with the way we make mistakes.

In his paper "The T-Experiments: Errors in Scientific Software"
(available at http://www.leshatton.org/IEEE_CSE_297.html ) Hatton
humorously describes the common kinds of errors made in Fortran
77, C, and C++. He seems to think that OO in C++ just increases the
number of possible errors that can be made.

"In Fortran, the scientist will be familiar with dependence on
uninitialised variables, inconsistent interfaces and so on. In C, the
delights of pointers add many new ways of getting it all wrong. In
C++,
even more sybaritic delights await the unwary, with the language
rapidly becoming so complex that any underlying science seems almost
irrelevant amidst the magic kingdom of polymorphism, inheritance,
object-orientation, over-loading, virtual methods, encapsulation and
vast numbers of hidden and frequently surprising actions performed on
behalf of the unwitting scientist by a grateful compiler. In contrast,
predicting the existence of a new sub-atomic particle seems
a relatively straightforward exercise."

"Pmb" <so*****@somewhere.com> wrote in message news:<b4********************@comcast.com>...

Hi. I'm new to this group. I'm refreshing/learning C++ and am starting to
learn Object Oriented Programming (OOP). In discussing this with people I
came up short as to what the benefits of OOP are. For example: As I
understand it, OOP has its main benefit in software reuse. Thus one develops
a software library of classes and this cuts down the overhead of reinventing
the wheel. Someone might say that this can be done with structured
programming with function libraries. So I have a few questions.

1) For those of you who like OOP, why do you like it?
2) Can OOP be accomplished with non-object oriented languages such as C?
3) If you're not part of a software engineering team but are programming
from your own use and don't need to reuse code would you bother with OOP?

Thanks

Pmb