Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Object Oriented Programming (OOP)

Reply
Thread Tools

Object Oriented Programming (OOP)

 
 
Dave Vandervies
Guest
Posts: n/a
 
      05-21-2004
In article <(E-Mail Removed)>,
Pmb <(E-Mail Removed)> 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 http://www.velocityreviews.com/forums/(E-Mail Removed)
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
 
Reply With Quote
 
 
 
 
Dave Vandervies
Guest
Posts: n/a
 
      05-21-2004
In article <(E-Mail Removed)>,
Pmb <(E-Mail Removed)> wrote:
>
>"Derek" <(E-Mail Removed)> 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 (E-Mail Removed)
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
 
Reply With Quote
 
 
 
 
Derek
Guest
Posts: n/a
 
      05-21-2004
> > 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."
 
Reply With Quote
 
Derek
Guest
Posts: n/a
 
      05-21-2004
> 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.
 
Reply With Quote
 
Thomas Matthews
Guest
Posts: n/a
 
      05-21-2004
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

 
Reply With Quote
 
Mike Wahler
Guest
Posts: n/a
 
      05-21-2004
"Pmb" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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


 
Reply With Quote
 
Dave Townsend
Guest
Posts: n/a
 
      05-21-2004
> 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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> "Allan Bruce" <(E-Mail Removed)> 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
>
>



 
Reply With Quote
 
Claudio Puviani
Guest
Posts: n/a
 
      05-21-2004
"Dave Townsend" <(E-Mail Removed)> 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


 
Reply With Quote
 
Pmb
Guest
Posts: n/a
 
      05-22-2004

"Jeff Relf" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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


 
Reply With Quote
 
Jeff Relf
Guest
Posts: n/a
 
      05-22-2004
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
New C++ Book - C++ For Artists: The Art. Philosophy, And Science Of Object-Oriented Programming Rick Miller C++ 1 09-19-2013 02:55 AM
class-oriented rather than object-oriented? notnorwegian@yahoo.se Python 2 05-26-2008 04:42 PM
C (functional programming) VS C++ (object oriented programming) Joe Mayo C Programming 168 10-22-2007 01:00 AM
Object oriented does not mean class oriented rolo Ruby 3 04-09-2004 02:51 PM
About object oriented programming Martin C++ 5 09-11-2003 06:15 PM



Advertisments