A question about understanding

Hello!

A friend of mine asked me the following question that is quite difficult to
answer. He use only C and can't find any problem with it.
Which problem is there when not using an OOP in solving problem compare to
when you using one OOP.

//Tony

"Tony Johansson" <johansson.andersson@telia.com> wrote in message news:TVCle.25657$d5.175455@newsb.telia.net...[color=blue]
> Hello!
>
> A friend of mine asked me the following question that is quite difficult to
> answer.[/color]

For whom? ;-)
[color=blue]
> He use only C and can't find any problem with it.
> Which problem is there when not using an OOP in solving problem compare to
> when you using one OOP.[/color]

Well, C and C++ are both general programming languages - anything you can do in one you can do in the other.

There are arguably some programming tasks which seem particularly suited to the OO paradigm; event-driven programming
(as in GUI's or games, for example) comes to mind. There are, equally, programming tasks for which OOP is likely to be
pretty pointless - sequential number-crunching scientific applications, for instance.

Also, be aware that C++ doesn't *enforce* OOP; it facilitates it. Likewise, C doesn't preclude OOP, but nor does it
particularly encourage it.

To give an example, I write mostly (non-GUI) scientific apps. I use C++, although most of the time I find myself using
very few of the OO features of the language (I can hardly remember when I last coded a virtual function). I could just
as well use C - the main reason I don't is because of other appealing aspects of C++ such as neater I/O, generic
programming (templates) and containers.

You choose your programming language/programming paradigm according to the task.

HTH,

--
Lionel B

Tony Johansson wrote:
[color=blue]
> Hello!
>
> A friend of mine asked me the following question that is quite difficult to
> answer. He use only C and can't find any problem with it.
> Which problem is there when not using an OOP in solving problem compare to
> when you using one OOP.[/color]


There is no silver-bullet solution. In most cases OO paradigm provides easier organisation
of data/concepts.

You may find the following useful:

http://www.itworld.com/AppDev/710/lw...up/page_1.html

http://www23.brinkster.com/noicys/do...eaking-cpp.pdf



--
Ioannis Vranos

http://www23.brinkster.com/noicys

Lionel B wrote:[color=blue]
> "Tony Johansson" <johansson.andersson@telia.com> wrote in message news:TVCle.25657$d5.175455@newsb.telia.net...[/color]
[color=blue][color=green]
>>He use only C and can't find any problem with it.
>>Which problem is there when not using an OOP in solving problem compare to
>>when you using one OOP.[/color][/color]

I believe there are instances where C is preferable to C++.
[color=blue]
> To give an example, I write mostly (non-GUI) scientific apps. I use C++, although most of the time I find myself using
> very few of the OO features of the language (I can hardly remember when I last coded a virtual function). I could just
> as well use C - the main reason I don't is because of other appealing aspects of C++ such as neater I/O, generic
> programming (templates) and containers.[/color]

I use C++ for scientific apps only. However, I use OO quite a bit!
Often, I find myself wishing that my counterparts gave OO a little more
consideration; especially when writing code that will be used by others
or become a part of an operational or quasi-operational system.

That's my rant for the day.

- dan

I agree with the authors of the two earlier posts, that you have to
choose the Paradigm/Language according to your task you have to solve.

But an important point of OOP is the use of Encasulation.
This means that you don't grant access to other pieces of Software if
you don't want it. The object is some sort of Blackbox. It (hopefully)
does what you want it to do, but how it does its job is not relevant to
the one using it. So it is possible to change the structure behind the
object without having to change the code depending on the object.

You may have a look at this book:
http://www.iam.unibe.ch/~ducasse/Fre...alk-and-OO.pdf

It describes the advantages of OOP to procedural programming.
It is based on and introduces Smalltalk a 'real' object oriented
programming language.

Manfred

Manfred wrote:[color=blue]
> I agree with the authors of the two earlier posts, that you have to
> choose the Paradigm/Language according to your task you have to solve.[/color]

In general I agree with your praise of encapsulation. But encapsulation
is not an OO feature but used in any reliably programming paradigm or
style. Also (especially!) in procedural C programming.
[color=blue]
> But an important point of OOP is the use of Encasulation.
> This means that you don't grant access to other pieces of Software if
> you don't want it. The object is some sort of Blackbox. It (hopefully)
> does what you want it to do, but how it does its job is not relevant to
> the one using it. So it is possible to change the structure behind the
> object without having to change the code depending on the object.[/color]

IMO, encapsulation is more important than polymorphism. The latter is a
real OO feature.

R.C.

In other words, there is not one only way that is suitable for everything.



--
Ioannis Vranos

http://www23.brinkster.com/noicys

Tony Johansson wrote:[color=blue]
>
> Hello!
>
> A friend of mine asked me the following question that is quite difficult to
> answer. He use only C and can't find any problem with it.
> Which problem is there when not using an OOP in solving problem compare to
> when you using one OOP.[/color]

Before you try top answer that question you should try to answer
another question first.

What problem can be solved in a high level language that cannot be
solved by programming in assembler?

Or another one:

What problem can be solved in assembler that cannot be solved by programming
the CPU with hex opcodes?

The thing is: OOP, High level languages, assembler, ... are not concepts
that solve real world problems. They are concepts that help the programmer
to get more productive by organizing the source code and taking away the
error prone, boring, repeating steps when creating a program.

--
Karl Heinz Buchegger
kbuchegg@gascad.at