Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > OOP vs procedural

Reply
Thread Tools

OOP vs procedural

 
 
Manuel
Guest
Posts: n/a
 
      01-03-2006
Please, excuse me for starting this discussion.
I'm not a troll, and I love the OOP architecture.
However I'm a C++ newbie, and sometimes it's hard for me to fully
understand the improvement of OOP. Please excuse my poor english too.
I hope it's sufficient to explain my question.

Generally OOP is better than procedural, but in a case I'm working on,
I'm not sure. This is an example of my doubts.

I'm writing a simple GUI openGL based.
I've some buttons, that must call some functions.

PROCEDURAL STYLE

I assume that:

-The button widget has an "identity".
-The identity is assigned when the button is created; example:
new Button("foo") assign the ID = "foo" to button created.
-The button widget has a boolean button.mouseOver.
-I use GLUT: when mouse is pressed, a callback is executed. This
callback check, for all buttons, if mouseOver is true.
-If mouseOver is true, the button return his ID

The procedural code is very simple (it's pseudo code):

------------------------------------------
//declare some functions

myfunction1(string)
myfunction2(int)
myfunction3(string, int)

//declare some buttons:

new Button("foo1");
new Button("foo2");
new Button("foo3");

//the mouse callback function for GLUT

mouse{
string ID
for each widget:
if widget.mouseOver == true:
switch(widget.getID())
case ("foo1"):
myfunction1(widget.getname())
case ("foo2"):
myfunction1(widget.getvalue())
case ("foo3"):
myfunction1(widget.getname(),widget.getvalue())
}
------------------------------------------

that's all.

What I see:
- It's flexible: I can link a button with any function I want, without
limits in number and type of arguments.
- It's readable and easy, even for a newbie.
- It don't need complex pattern, pointers, and avoid memory lacks or
dangling references possibilities.


However, I know, it's not fully OOP. So some coders, experts in C++,
tell me that I should use functionoids. So I'm starting from here:

http://www.parashift.com/c++-faq-lit...html#faq-33.10

but I don't understand why functionoids (in this case) is better.
I've not fully followed them, however seem that, in order to use them, I
must write a lot of extra code (very complex for me) lines.

1) I must write a base class with a pure-virtual method
2) I must write a derived classes for each function (so if I've 100
functions, I must write 100 derived classes ?)
3) how to delete the pointers created by a functionoids? Maybe for you
(gurus of C++) this is easy, but for a newbie/medium level coder this
mean a lot of difficults, hard debug, possible memory lacks or dangling
references.

Note that I must write, in both cases, the same number of functions.
But in second case, it's not sufficient write a simple function, but
it's needed insert it in the functionoid pattern...so I'm almost sure
that the lines to write is increased in second case.

However, the doubt is not only about the increase of complexity, but
about the advantages of functionoids (alway, in this particular case);
again, I admit to have not fully understand functionoids, but seem that
advantages is about the arguments that is possible to pass:

"Then later you pass the remaining args using that pointer, and the
system magically takes your original args (that were freeze-dried),
combines them with any local variables that the function calculated
prior to being freeze-dried, combines all that with the newly passed
args, and continues the function's execution where it left off when it
was freeze-dried. "

This sound good! But I've all flexibility I need with procedural
approach: the buttons can call any type of function, with any type and
number of parameters, mixing local variable with widgets variables...

To conclude, I quote "Thinking in C++", vol.2 chapter 10:
-------------------------------------------------------
"Understanding inheritance and polymorphism is such a challenge that you
may begin to assign undue importance to these techniques. We see many
over-complicated designs (our own included) that result from
"inheritance indulgence"- for example, many multiple inheritance
designs evolve by insisting that inheritance be used everywhere.

One of the guidelines in Extreme Programming is "Do the simplest thing
that could possibly work." A design that seems to want inheritance can
often be dramatically simplified by using composition instead, and you
will also discover that the result is more flexible, as you will
understand by studying some of the design patterns in this chapter. So
when pondering a design, ask yourself: "Could this be simpler using
composition? Do I really need inheritance here, and what is it buying me?"
-------------------------------------------------------

So, the final question is: in this SPECIFIC case is really true that OOP
is better of procedural?

Please, remember I'm only a newbie, and maybe I can't see the advantages
of OOP in this case because my little knowledge of C++, or maybe exist a
better OOP way that don't require complex functionoids and I don't know
because my ignorance.
Again, I'm not a troll...only I want understand deeply because all tell
me I must use, for this simple GUI, a different approach, not "switch
based".

I hope to don't boring you, and please, don't reply me so hard...

regards,

Manuel

 
Reply With Quote
 
 
 
 
puzzlecracker
Guest
Posts: n/a
 
      01-03-2006

Manuel wrote:
> Please, excuse me for starting this discussion.
> I'm not a troll, and I love the OOP architecture.
> However I'm a C++ newbie, and sometimes it's hard for me to fully
> understand the improvement of OOP. Please excuse my poor english too.
> I hope it's sufficient to explain my question.
>
> Generally OOP is better than procedural, but in a case I'm working on,
> I'm not sure. This is an example of my doubts.
>
> I'm writing a simple GUI openGL based.
> I've some buttons, that must call some functions.
>
> PROCEDURAL STYLE
>
> I assume that:
>
> -The button widget has an "identity".
> -The identity is assigned when the button is created; example:
> new Button("foo") assign the ID = "foo" to button created.
> -The button widget has a boolean button.mouseOver.
> -I use GLUT: when mouse is pressed, a callback is executed. This
> callback check, for all buttons, if mouseOver is true.
> -If mouseOver is true, the button return his ID
>
> The procedural code is very simple (it's pseudo code):
>
> ------------------------------------------
> //declare some functions
>
> myfunction1(string)
> myfunction2(int)
> myfunction3(string, int)
>
> //declare some buttons:
>
> new Button("foo1");
> new Button("foo2");
> new Button("foo3");
>
> //the mouse callback function for GLUT
>
> mouse{
> string ID
> for each widget:
> if widget.mouseOver == true:
> switch(widget.getID())
> case ("foo1"):
> myfunction1(widget.getname())
> case ("foo2"):
> myfunction1(widget.getvalue())
> case ("foo3"):
> myfunction1(widget.getname(),widget.getvalue())
> }
> ------------------------------------------
>
> that's all.
>
> What I see:
> - It's flexible: I can link a button with any function I want, without
> limits in number and type of arguments.
> - It's readable and easy, even for a newbie.
> - It don't need complex pattern, pointers, and avoid memory lacks or
> dangling references possibilities.
>
>
> However, I know, it's not fully OOP. So some coders, experts in C++,
> tell me that I should use functionoids. So I'm starting from here:
>
> http://www.parashift.com/c++-faq-lit...html#faq-33.10
>
> but I don't understand why functionoids (in this case) is better.
> I've not fully followed them, however seem that, in order to use them, I
> must write a lot of extra code (very complex for me) lines.
>
> 1) I must write a base class with a pure-virtual method
> 2) I must write a derived classes for each function (so if I've 100
> functions, I must write 100 derived classes ?)
> 3) how to delete the pointers created by a functionoids? Maybe for you
> (gurus of C++) this is easy, but for a newbie/medium level coder this
> mean a lot of difficults, hard debug, possible memory lacks or dangling
> references.
>
> Note that I must write, in both cases, the same number of functions.
> But in second case, it's not sufficient write a simple function, but
> it's needed insert it in the functionoid pattern...so I'm almost sure
> that the lines to write is increased in second case.
>
> However, the doubt is not only about the increase of complexity, but
> about the advantages of functionoids (alway, in this particular case);
> again, I admit to have not fully understand functionoids, but seem that
> advantages is about the arguments that is possible to pass:
>
> "Then later you pass the remaining args using that pointer, and the
> system magically takes your original args (that were freeze-dried),
> combines them with any local variables that the function calculated
> prior to being freeze-dried, combines all that with the newly passed
> args, and continues the function's execution where it left off when it
> was freeze-dried. "
>
> This sound good! But I've all flexibility I need with procedural
> approach: the buttons can call any type of function, with any type and
> number of parameters, mixing local variable with widgets variables...
>
> To conclude, I quote "Thinking in C++", vol.2 chapter 10:
> -------------------------------------------------------
> "Understanding inheritance and polymorphism is such a challenge that you
> may begin to assign undue importance to these techniques. We see many
> over-complicated designs (our own included) that result from
> "inheritance indulgence""- for example, many multiple inheritance
> designs evolve by insisting that inheritance be used everywhere.
>
> One of the guidelines in Extreme Programming is "Do the simplest thing
> that could possibly work." A design that seems to want inheritance can
> often be dramatically simplified by using composition instead, and you
> will also discover that the result is more flexible, as you will
> understand by studying some of the design patterns in this chapter. So
> when pondering a design, ask yourself: "Could this be simpler using
> composition? Do I really need inheritance here, and what is it buying me?"
> -------------------------------------------------------
>
> So, the final question is: in this SPECIFIC case is really true that OOP
> is better of procedural?
>
> Please, remember I'm only a newbie, and maybe I can't see the advantages
> of OOP in this case because my little knowledge of C++, or maybe exist a
> better OOP way that don't require complex functionoids and I don't know
> because my ignorance.
> Again, I'm not a troll...only I want understand deeply because all tell
> me I must use, for this simple GUI, a different approach, not "switch
> based".
>
> I hope to don't boring you, and please, don't reply me so hard...
>
> regards,
>
> Manuel



No problem Manual, but you need to find more appropriate usenet groups
that deals with your questions - you can still post c++ related
questions here, and we will gladly answer and discuss them with you; I
haven't found any in your post. For oo design - take a look at
comp.object.

Similarly, we usually do not do homeworks for others but only help with
language specific obstacles. I am sure you can find resourses only
wherein your assignments can be completed for a certain payment.


Good luck

 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      01-03-2006
puzzlecracker wrote:
> Manuel wrote:
>> Please, excuse me for starting this discussion.


[..excessive quoting removed..]

>>
>> regards,
>>
>> Manuel

>
>
> No problem Manual, but [..]


Two mistakes, as I see it. Misspelling of the OP's name and
excessive quoting of what is deemed to be essentially an off-
topic posting. Your reply is to the point, though, and quite
informative. Keep at it.


 
Reply With Quote
 
Manuel
Guest
Posts: n/a
 
      01-03-2006
puzzlecracker wrote:

>
> No problem Manual, but you need to find more appropriate usenet groups
> that deals with your questions - you can still post c++ related
> questions here, and we will gladly answer and discuss them with you; I
> haven't found any in your post. For oo design - take a look at
> comp.object.


I think OOP is strongly related to OOP.
In this case in particular (I've underlined various time it's specific
case) it's about use of C++ pattern I've linked, called functionoid.


>
> Similarly, we usually do not do homeworks for others but only help with
> language specific obstacles.


Eh..eh!
Really I wish this was an homework...
The fact I'm C++ newbie not mean I'm young...
my first computer was msx 128 Kb ram...


>I am sure you can find resourses only
> wherein your assignments can be completed for a certain payment.



Payment?
So I must explain details.
I've developed this Open Source project (so free, gratis ect..) since 2000:

www.makehuman.org

for some reason the project is changed, from python (that I know)
to C++. So I need to study C++, to port python code (in this case GUI)
in C++.

I hope anyone want help me as I've helped the opensource community for
years...

Regards,

Manuel
 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      01-03-2006
Manuel wrote:

> Please, excuse me for starting this discussion.


No prob - I added comp.object to the newsgroup list.

> I'm not a troll, and I love the OOP architecture.


OOP sucks. Feel free to diss it; honestly disagreeing with a newsgroup's
average opinion is not trolling.

> Generally OOP is better than procedural, but in a case I'm working on, I'm
> not sure. This is an example of my doubts.


OOP subsumes procedural, and adds a new technique - polymorphism. For a
given design, if you don't need the technique, don't use it. Polymorphism is
not automatically "better".

> I'm writing a simple GUI openGL based.


Ouch. Okay, polymorphism is automatically better!

> I've some buttons, that must call some functions.
>
> PROCEDURAL STYLE
>
> I assume that:
>
> -The button widget has an "identity".
> -The identity is assigned when the button is created; example:
> new Button("foo") assign the ID = "foo" to button created.
> -The button widget has a boolean button.mouseOver.
> -I use GLUT: when mouse is pressed, a callback is executed. This callback
> check, for all buttons, if mouseOver is true.
> -If mouseOver is true, the button return his ID
>
> The procedural code is very simple (it's pseudo code):
>
> ------------------------------------------
> //declare some functions
>
> myfunction1(string)
> myfunction2(int)
> myfunction3(string, int)
>
> //declare some buttons:
>
> new Button("foo1");
> new Button("foo2");
> new Button("foo3");
>
> //the mouse callback function for GLUT
>
> mouse{
> string ID
> for each widget:
> if widget.mouseOver == true:
> switch(widget.getID())
> case ("foo1"):
> myfunction1(widget.getname())
> case ("foo2"):
> myfunction1(widget.getvalue())
> case ("foo3"):
> myfunction1(widget.getname(),widget.getvalue())
> }
> ------------------------------------------
>
> that's all.
>
> What I see:
> - It's flexible: I can link a button with any function I want, without
> limits in number and type of arguments.
> - It's readable and easy, even for a newbie.
> - It don't need complex pattern, pointers, and avoid memory lacks or
> dangling references possibilities.


The big problem is this: If you want to add a new capacity to all buttons,
you must find a list of switch/case statements, clone it, and change all the
target functions.

Then, if you want to add a new button, you must find every list of switch
case statements that list buttons, then add the new button to the list.

> However, I know, it's not fully OOP. So some coders, experts in C++, tell
> me that I should use functionoids. So I'm starting from here:
>
> http://www.parashift.com/c++-faq-lit...html#faq-33.10
>
> but I don't understand why functionoids (in this case) is better.
> I've not fully followed them, however seem that, in order to use them, I
> must write a lot of extra code (very complex for me) lines.


Focus on the big problem I listed. How can you define new buttons in only
one place, and define new functions for buttons in only one place? How can
you replace this...

switch(widget.getID())
case ("foo1"):
myfunction1(widget.getname())
case ("foo2"):
myfunction1(widget.getvalue())

with this:

widget.myfunction();

Different widgets respond to myfunction() with different methods.

> 1) I must write a base class with a pure-virtual method


Or write a virtual method with nothing in it.

> 2) I must write a derived classes for each function (so if I've 100
> functions, I must write 100 derived classes ?)


No. Write a derived class for each method that differs. Most will be the
same. Each class may have fewer methods than its parent class.

In a GUI, when you perform a trivial action like skate the mouse back and
forth, most widgets don't implement their "rollover()" method. They do
nothing at rollover time, so your putative base class would have a
rollover() with nothing in it.

Only those few widgets that pop up a tooltip or change their appearance at
rollover time would implement that function.

> 3) how to delete the pointers created by a functionoids? Maybe for you
> (gurus of C++) this is easy, but for a newbie/medium level coder this mean
> a lot of difficults, hard debug, possible memory lacks or dangling
> references.


In this specific case, don't 'new' them, hence don't 'delete' them. Put them
in your global space before main().

You will eventually need to Google for "smart pointer".

> Note that I must write, in both cases, the same number of functions.
> But in second case, it's not sufficient write a simple function, but it's
> needed insert it in the functionoid pattern...so I'm almost sure that the
> lines to write is increased in second case.


The point is to write much fewer functions, and fewer lines in each
function, while increasing your ability to change classes and functions
easily.

> However, the doubt is not only about the increase of complexity, but about
> the advantages of functionoids (alway, in this particular case); again, I
> admit to have not fully understand functionoids, but seem that advantages
> is about the arguments that is possible to pass:
>
> "Then later you pass the remaining args using that pointer, and the system
> magically takes your original args (that were freeze-dried), combines them
> with any local variables that the function calculated prior to being
> freeze-dried, combines all that with the newly passed args, and continues
> the function's execution where it left off when it was freeze-dried. "
>
> This sound good!


It's wrong, and it's not "OOP". All functions should take the same, single
parameter - probably an Event object. And if your GUI has different kinds of
events (keyboard, mouse, etc.), then these should also have derived classes
with different virtual methods. So MouseEvent::getXY() returns the mouse
location relative to your GUI, and KeyboardEvent::getXY() returns a location
relative to the control with the keyboard focus.

When your input parameter is a reference to a polymorphic object, then it
typesafely expresses the kind of polymorphism which your variable argument
trick attempts to express.

> But I've all flexibility I need with procedural approach: the buttons can
> call any type of function, with any type and number of parameters, mixing
> local variable with widgets variables...


You mean that you have the flexibility to write different kinds of lines
inside each case of each switch statement. Sometimes that's the flexibility
you need. However...

Imagine if all widgets can respond to several kinds of events. Mouse,
Keyboard, Timer, Network, Collision, etc. You need one switch/case for each
of those. Now to add a widget, you have to write new lines into each
switch/case. Oh, and you have a different XY system for each kind of widget
that needs XY, and you repeat this system for each kind of Event that
supplies a default screen location. You must re-type all that each time you
add new events or new widgets.

The flexibility to perform lots and lots of typing is _not_ the kind of
flexibility we need.

So instead if you have this...

pWidget->doEvent(pEvent);

....then some doEvent() implementations do nothing. Some call
pEvent->getXY(). This sometimes pulls the hardware mouse's location, and
sometimes reads the location from a widget. To add new widgets and events
you only write their class, and inside it you override and change only the
few methods that differ.

> To conclude, I quote "Thinking in C++", vol.2 chapter 10:
> -------------------------------------------------------
> "Understanding inheritance and polymorphism is such a challenge that you
> may begin to assign undue importance to these techniques. We see many
> over-complicated designs (our own included) that result from "inheritance
> indulgence"- for example, many multiple inheritance designs evolve by
> insisting that inheritance be used everywhere.
>
> One of the guidelines in Extreme Programming is "Do the simplest thing
> that could possibly work." A design that seems to want inheritance can
> often be dramatically simplified by using composition instead, and you
> will also discover that the result is more flexible, as you will
> understand by studying some of the design patterns in this chapter. So
> when pondering a design, ask yourself: "Could this be simpler using
> composition? Do I really need inheritance here, and what is it buying me?"
>

-------------------------------------------------------

The XP slogan "do simple things" applies _after_ you learn how to simplify
complex designs. (The correct books for this are /Refactoring/, and
/Refactoring to Patterns/). It does not mean the simplest design to code. XP
also expects you to add features to code without adding bugs or lowering its
design quality. If you don't clean up early, and use virtual methods where
they reduce the line count, then later you will add lots of patches and
hacks, such as global variables, to add new features.

> So, the final question is: in this SPECIFIC case is really true that OOP
> is better of procedural?


Uh, all the best GUIs use OOP, generally like I said, to polymorph their
widgets.

> Please, remember I'm only a newbie, and maybe I can't see the advantages
> of OOP in this case because my little knowledge of C++, or maybe exist a
> better OOP way that don't require complex functionoids and I don't know
> because my ignorance.


You have in fact asked the most important question about OOP - how to
replace a switch statement with polymorphism. There are those who call this
the "Replace Conditional with Polymorphism Refactor".

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!


 
Reply With Quote
 
Manuel
Guest
Posts: n/a
 
      01-03-2006
Victor Bazarov wrote:

>
> Two mistakes, as I see it. Misspelling of the OP's name and


Eh?
OOP = Object-Oriented Programming
where is the error?
 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      01-03-2006
Manuel wrote:
> [..]
> I think OOP is strongly related to OOP.


Uh... As strongly as you're related to yourself, my guess would be.

> In this case in particular (I've underlined various time it's specific
> case) it's about use of C++ pattern I've linked, called functionoid.


Yes, but the principals and topics you're discussing (or wishing to
discuss) are not language-specific, and 'comp.object' NG is, in fact,
a much better place for that. Also, consider comp.programming for
comparing procedural and OO types of programming, since procedural
(functional) programming would probably be off-topic in comp.object.

Just my $0.02...

V


 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      01-03-2006
Manuel wrote:
> Victor Bazarov wrote:
>
>>
>> Two mistakes, as I see it. Misspelling of the OP's name and

>
> Eh?


What? I wasn't replying to you and I wasn't talking of your
mistakes.

> OOP = Object-Oriented Programming
> where is the error?


Your name is ManuEl, the spelling used was ManuAl. That is
a mistake as I see it. BTW, 'OP' means "Original Poster" in
Usenet speak.

V


 
Reply With Quote
 
Manuel
Guest
Posts: n/a
 
      01-03-2006
Victor Bazarov wrote:
> Manuel wrote:
>
>>[..]
>>I think OOP is strongly related to OOP.

>
>
> Uh... As strongly as you're related to yourself, my guess would be.


Sorry...I mean I think OOP is strongly related to CPP.
I'm a bit tired...

Ciao,

Manuel
 
Reply With Quote
 
Manuel
Guest
Posts: n/a
 
      01-03-2006
Phlip wrote:

>
> Imagine if all widgets can respond to several kinds of events. Mouse,
> Keyboard, Timer, Network, Collision, etc. You need one switch/case for each
> of those. Now to add a widget, you have to write new lines into each
> switch/case. Oh, and you have a different XY system for each kind of widget
> that needs XY, and you repeat this system for each kind of Event that
> supplies a default screen location. You must re-type all that each time you
> add new events or new widgets.
>
> The flexibility to perform lots and lots of typing is _not_ the kind of
> flexibility we need.


Hi Phlip,
Thanks for long reply...
I've almost completely understand the problem, you are very clear.

The simple classes I'm writing already have partially the
polymorphism...: setThis(), doThat(), etc.. a base widget class with
virtual functions to be inherit...etc...
In example, a loop like

for widget in widgetList:
widget.draw()

Draw all widgets type, because draw is a virtual function, with
different meaning in various derivated classes.

But all these methods change the internal status of widget itself, or do
internal functions, or change the status of openGL machine, and this is
very easy.

The problem is to link the button with a specific "external" function.

So my post was related only to these special functions...about how to
call them in application code. So, it is almost impossible to write more
of one case for each button. And to add a method to widget is not
related to switch/case...I can add all methods/property I want...only
the main callback need to parsed in switch/case...



Ah...before continue...this is not an homework! I'm too old to have
homework This is related to this opensource project:

www.makehuman.org

However, reading your reply, I'm thinking that maybe is not needed the
functionoids. It's not sufficient pass a pointer_to_function as argument
of button?


Thanks,
Manuel
 
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
Is implementing a Java class procedural programming? tenxian Java 10 04-25-2008 05:02 PM
Converting procedural type code to OO code Mohitz C++ 4 07-12-2007 07:23 PM
Re: Should I learn procedural Pascal before Delphi ? chuayongquan@hotmail.com Digital Photography 3 02-28-2005 08:09 AM
help: good sturdy C procedural program design John Gabriele C Programming 2 04-24-2004 04:13 PM
Procedural ["bare ASP.NET"] versus OOPy ASP.NET parley ASP .Net 13 02-11-2004 01:26 AM



Advertisments