OOP vs procedural

Discussion in 'C++' started by Manuel, Jan 3, 2006.

  1. Manuel

    Manuel Guest

    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
     
    Manuel, Jan 3, 2006
    #1
    1. Advertising

  2. 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-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
     
    puzzlecracker, Jan 3, 2006
    #2
    1. Advertising

  3. 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.
     
    Victor Bazarov, Jan 3, 2006
    #3
  4. Manuel

    Manuel Guest

    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
     
    Manuel, Jan 3, 2006
    #4
  5. Manuel

    Phlip Guest

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

    --
    Phlip
    http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
     
    Phlip, Jan 3, 2006
    #5
  6. Manuel

    Manuel Guest

    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?
     
    Manuel, Jan 3, 2006
    #6
  7. 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
     
    Victor Bazarov, Jan 3, 2006
    #7
  8. 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
     
    Victor Bazarov, Jan 3, 2006
    #8
  9. Manuel

    Manuel Guest

    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
     
    Manuel, Jan 3, 2006
    #9
  10. Manuel

    Manuel Guest

    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
     
    Manuel, Jan 3, 2006
    #10
  11. Manuel

    Phlip Guest

    Manuel wrote:

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

    --
    Phlip
    http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
     
    Phlip, Jan 3, 2006
    #11
  12. Manuel

    topmind Guest

    > 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, Jan 3, 2006
    #12
  13. Manuel

    topmind Guest

    > 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, Jan 3, 2006
    #13
  14. Manuel

    Manuel Guest

    Phlip wrote:

    > 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;
    }


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

    Thanks for help,

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

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


    .... 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
     
    Sebastian Wiesner, Jan 3, 2006
    #15
  16. Manuel

    James Guest

    Good points topmind.
     
    James, Jan 8, 2006
    #16
  17. Manuel

    James Guest

    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.
     
    James, Jan 8, 2006
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. parley
    Replies:
    13
    Views:
    768
    jim corey
    Feb 11, 2004
  2. John Gabriele

    help: good sturdy C procedural program design

    John Gabriele, Apr 24, 2004, in forum: C Programming
    Replies:
    2
    Views:
    514
    John Gabriele
    Apr 24, 2004
  3. Mohitz
    Replies:
    4
    Views:
    472
    Jim Langston
    Jul 12, 2007
  4. tenxian
    Replies:
    10
    Views:
    2,788
    Mark Space
    Apr 25, 2008
  5. tenxian
    Replies:
    0
    Views:
    278
    tenxian
    Apr 25, 2008
Loading...

Share This Page