Object Oriented Programming (OOP)

[Dave Vandervies]

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]

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

 

[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."

 

[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]

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]

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!

 

[Claudio Puviani]

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]

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=define:modal&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]

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]

easier

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]

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."