Thread: Transition between PP and OOP

  1. #1
    Registered User
    Join Date
    Aug 2001
    Posts
    84

    Transition between PP and OOP

    I am pretty comfortable with functions , loops and decision making
    aspects of c++ and have written some very basic programs
    using these techniques.

    Now i am trying to get the hang of OOP and I am struggling to
    make programs which use classes effectively.

    I understand constructors, destructors , pointers to objects,
    arrays of objects but as yet cant put my knowledge into
    decent examples.

    1. Does everyone struggle like this at first?

    I havent got to sections on inheritance , virtual functions
    or class templates.

    2. Should i still be able to complete any program i set my mind
    without inheritance virtual functions and templates but with
    just different program design?

  2. #2
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297

    Re: Transition between PP and OOP

    Originally posted by The Gweech
    1. Does everyone struggle like this at first?
    I think so. Unless its the first thing you learned. Don't worry too much about that. It'll click.

    Originally posted by The Gweech
    2. Should i still be able to complete any program i set my mind
    without inheritance virtual functions and templates but with
    just different program design?
    well sort of. inheritance is pretty darn good for eliminating duplicate code in similar objects. (some think its bad design to inherit functionality) You don't really need to use templates but there will come a day when you find them useful. Don't worry about them for now. As far as the whole virtual function thing goes. Think about all the situations in C where you might have used a switch of some kind, based on what "type" of thing you were working on. those are where you would use a virtual functions. the cat and dog examples are pretty good for that. dog.Speak() cat.Speak() virtual functions called very simply

    animal->Speak();

    In C you would have written something like this:
    Code:
    Speak(animalptr, type)
       {
       switch(type)
          {
          case DOG:
             -----do dog stuff----
             break;
          case CAT:
             -----do cat stuff----
             break;
          }
       }
    So I don't think you should try to get away from virtual function inheritance.

  3. #3
    Registered User
    Join Date
    Aug 2001
    Posts
    84
    Thanks FillYourBrain that has put another few pieces of the
    puzzle into place. A big problem for me is when does something
    qualify to become a class.

    What would help me if someone could tell me what would be
    written as a class in the following scenaries.(No code expected)

    1. Number guessing game.
    2. Tic-Tac-Toe
    3. Fruit Machine
    4. PacMan.

    My thoughts or guesses off the top of my head would be

    1. a Guess.
    2. The board , The 0's and 1's.
    3. The reels.
    4. The Maze , Pacman, The monsters.

    I dont really have a clue but I thought it only right to have a go.

    Can anyone put me straight ?
    Even better could people just give me different scenarios
    and how classes would be used in those scenarios.

  4. #4
    Banned Troll_King's Avatar
    Join Date
    Oct 2001
    Posts
    1,784
    -"A Guess" would be an attribute of a class.

    A class contains data (attributes) and behavior (methods), and you communicate with it through its interface. A class is an specification for an object.

    The best way to understand objects is to study UML. In addition there are a few other references but why don't you plod your way as far as possible through your book, than read 'The UML Users Guide' and 'The Unified Software Development Process'. In addition, if you want to know how to identify classes than learn what a 'Use Case' is.

    You can get a free UML spec at www.omg.org however there is a series of books that are easier reading.

  5. #5
    Seeking motivation... endo's Avatar
    Join Date
    May 2002
    Posts
    537
    OO design is quite subjective in my opinion. Its very tough to decide what should be a class and what should be an attribute of a class. For your examples, I wouldnt use classes for the first - seems a little unnecessary. Tictactoe, same as you - probably a board, and playing pieces to be X's and O's (this can be a good example of inheritance and polymorphic behaviour). Fruit machine, probably a class for the reels, the machine and possibly other depending on other the complexity of the reels. Pacman is similar to tactactoe - a board, pacman, and ghosts (again using a class heirarchy 'cos these will be very similar).

    Like I say though, it subjective. My current database program has about 15 classes and the design still isnt quite right, so might need more or might have to remove some. Decisions, decisions...
    Couldn't think of anything interesting, cool or funny - sorry.

  6. #6
    Banned Troll_King's Avatar
    Join Date
    Oct 2001
    Posts
    1,784
    Object Oriented Design Heuristics

    Arthur J. Riel

  7. #7
    Registered User
    Join Date
    Aug 2001
    Posts
    84
    Troll King the book you mentioned is it for advanced users
    of c++ or would a newbie be okay ( I know the syntax of c++)

    I was thinking of the subject of a football manager game
    and how classes would tackle the problem.

    1. The football player (age,position,skill, blah)
    2. The team(games played,league position)
    3. The league(Number of teams)

    Where would these following things fit into the classes

    1.The season
    2. Would the knockout competition have its own class
    3. Transfers markets.

    and how would polymorphism , inheritance be used in this
    scenario.

    Can anyone give any insight how they would tackle this problem.

  8. #8
    Green Member Cshot's Avatar
    Join Date
    Jun 2002
    Posts
    892
    Start off with a calculator program.

  9. #9
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    Originally posted by The Gweech
    Troll King the book you mentioned is it for advanced users
    of c++ or would a newbie be okay ( I know the syntax of c++)

    I was thinking of the subject of a football manager game
    and how classes would tackle the problem.

    1. The football player (age,position,skill, blah)
    2. The team(games played,league position)
    3. The league(Number of teams)

    Where would these following things fit into the classes

    1.The season
    2. Would the knockout competition have its own class
    3. Transfers markets.

    and how would polymorphism , inheritance be used in this
    scenario.

    Can anyone give any insight how they would tackle this problem.
    team should probably contain a list of players, league a list of teams etc...

    season KO and market seem to be modes of the game? is that right? That could be done a couple ways. I would probably like to be able to make those calls on a "game" object.

    game.Season()
    or
    game.KOCompetition()

    etc...

    I don't know. It's pretty good to just remember to think like a human when developing OOP architecture. in a game is a series of modes (mode objects). In a season is a series of games (game objects). In a team is a series of players. Well, you get the idea. OOP is a higher level of abstraction. It makes it so you don't have to think like a computer when designing.
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  10. #10
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    oh and you were asking for us to point out polymorphism.

    I'm thinking the modes all use graphics in some form right? all modes that use graphics might have set of graphics ability. Maybe your mouse and keyboard code also. There's one small hierarchy.

    how about 3d objects? 3dobjects have lists of polygons. probably rotations and translations also. I think field, player, ball, ref, etc... probably gets derived from a 3dobject thing.

    Players could be broken up further. defensive/offensive players maybe?
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

Popular pages Recent additions subscribe to a feed