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?

Quote:

---

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.

Quote:

---

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.

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.

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

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

Object Oriented Design Heuristics

Arthur J. Riel

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.

Start off with a calculator program.

Quote:

---

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.

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?