OOP vs procedural

[Manuel]

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-lite/pointers-to-members.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

 

[puzzlecracker]

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-lite/pointers-to-members.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

 

[Victor Bazarov]

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

 

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

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

 

[Phlip]

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-lite/pointers-to-members.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".

 

[Manuel]

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

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

 

[Victor Bazarov]

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

 

[Victor Bazarov]

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

 

[Manuel]

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

 

[Manuel]

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

 

[Phlip]

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

Now the question is "what's an object?"

Not just widgets should be objects. Anything that has functions should be
objects. So the answer is "the thing that needs this external function
should itself also be an object".

And this topic is leading us to Observer Pattern and Model View Controller.
Look them up, and crack the book /Design Patterns/.

Ah...before continue...this is not an homework!

You are allowed to post questions about learning projects, so long as you
make a good-faith effort yourself, which you have done.

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?

Try this:

EditField nameField;
EditField addressField;
MaskField zipCode("99999");

....

switch(ID)
case ("name"):
return nameField;
case ("address"):
return addressField;
case ("zip"):
return zipCode;
...

The switch happens only once, to turn an ID into an object. (This always
happens at the boundary of a program.) So all remaining functions can pass a
Widget & around, and all these classes inherit Widget.

 

[topmind]

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.

This depends on the implementation of the buttons. Often lots of
switch/case statements are a suggeston that perhaps a data structure
should be used instead (I prefer tables, but they are not
well-supported of late). If every element of the structure is to get
(inherit) new behavior, then you simply add it in the one place that
processes the structure, all without OOP.

However, the tricky part is when some get such behavior and some don't.
If the pattern is not hierarchical, then inheritance (and possibly
polymorphism) can turn into a mess.

I have been round-and-round with regards to case/switch statements and
OOP. I do not buy the general argument that case/switch statements are
necessarily more code or more duplication. For an example of a long
prior debate, see:

http://www.c2.com/cgi/wiki?SwitchStatementsSmell

Further, I don't think GUI engines should be tied to one particular
language because it means reinventing the wheel for each language; and
a language-neutral GUI system will be less likely to use polymorphism.

-T-

 

[topmind]

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.

This depends on the implementation of the buttons. Often lots of
switch/case statements are a suggeston that perhaps a data structure
should be used instead (I prefer tables, but they are not
well-supported of late). If every element of the structure is to get
(inherit) new behavior, then you simply add it in the one place that
processes the structure, all without OOP.

However, the tricky part is when some get such behavior and some don't.
If the pattern is not hierarchical, then inheritance (and possibly
polymorphism) can turn into a mess.

I have been round-and-round with regards to case/switch statements and
OOP. I do not buy the general argument that case/switch statements are
necessarily more code or more duplication. For an example of a long
prior debate, see:

http://www.c2.com/cgi/wiki?SwitchStatementsSmell

Further, I don't think GUI engines should be tied to one particular
language because it means reinventing the wheel for each language; and
a language-neutral GUI system will be less likely to use polymorphism.

-T-

 

[Manuel]

You are allowed to post questions about learning projects, so long as you
make a good-faith effort yourself, which you have done.
Thanks...


Try this:

EditField nameField;
EditField addressField;
MaskField zipCode("99999");
....

The switch happens only once, to turn an ID into an object. (This always
happens at the boundary of a program.) So all remaining functions can pass a
Widget & around, and all these classes inherit Widget.

The "old" switch happen only once too...


I've written a better example to show the question:
what's the difference returning an object instead an ID ?

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

#include "mhcontainer.h"
#include "mhwidget.h"
#include "square.h"
#include "mesh.h"

mesh meshObj; //mesh class to handle the geometry
mhcontainer widgetContainer //A canvas class to contain widgets

//Some functions that use local objs

void applymorph(){
meshObj.function1();
meshObj.getThis();
meshObj.getThat();
}

void smoothMesh(){
meshObj.function2();
meshObj.getThis2();
meshObj.getThat2();
}

void hideContainer(){
widgetContainer.setOff()
aFuntion();
anotherFuntion();
}


//THIS IS THE NOT OOP FUNCTION!!!!!
//Pseudocode here!!!
void mouseFunction(x, y ){
for each widget in widgetContainer:
if widgetContainer.getStatus() == on:
if widget.onMouseOver(x,y) == true:

switch(widget.ID):
case (Morphing): applymorph()
case (Smooth): smoothMesh()
case (Close): hideContainer()


int main ( int argc, char** argv )
{

widgetContainer.addWidget(new Button ("Morphing"));
widgetContainer.addWidget(new Button ("Smooth"));
widgetContainer.addWidget(new Button ("Close"));

glutInit ( &argc, argv );
MainWindow.initWindow();
glutReshapeFunc ( reshape );
glutDisplayFunc ( display );
glutMouseFunc ( mouseFunction ); //MOUSE FUNCTION NO OOP!!!!
glutMainLoop ( );
system("PAUSE");
return 0;
}

 

[Sebastian Wiesner]

Once upon a time (Dienstag, 3. Januar 2006 02:50) Manuel wrote some very
nice things

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

.... and to many other programming languages like Java, C#, Smalltalk, and
many more. Your question is not C++ specific and should be posted
somewhere else.

Sebastian

 

[James]

Good points topmind.

 

[James]

I think this thread is rather worrying, because most everyone is
focused on the use of polymorphism within a particular objects methods.
However, the thing that appears to be glossed over is the use of
"swtch/case" which isnt necessary if OOP is used.
This code should be simple like the following (given in psuedocode)

:
widgetContainer.applyToEachWidget(myFunctionObjectThatTakesOnArgument)
:

The "myFunctionObject" would then receive a widget object and on each
one it would invoke the same function.
ie: it would not do a "switch" on the widgetID as each widget should
have an "understanding" of what a widget
can do. For example, each widget might understand the message
"doAction()" and in response to this it
does the "Morph", "Smooth" or "hide". The caller does not have to
determine which method to invoke.

Polymorphism isnt just about sending different parameters to the same
method name.
Think in terms of a set of "like" objects, in this case widgets, all
understanding the same message "doAction" or
"handleMouseEvent". This way to code is smaller, clearer and faster.

I hope this helps.

Rgs, James.