OOPs, I did it again.... lol....

This is a discussion on OOPs, I did it again.... lol.... within the C++ Programming forums, part of the General Programming Boards category; I thought it was funny..... Anyways....
Object Oriented Programmers = Engineers?
Objects - bits of code that should be able ...

Object oriented programming is about treating things as objects. Consider an object such as a box. YOu can look at it and get all kinds of information from it. It's dimensions, it's color, it's material, it's contents. You wouldn't go and get this information from something unrelated.
In an OOP program we can cobine all of this information into a class and once we create an instance of that class we can access all the information about that class by using member variables and meathods of that class.
for example we could call a meathod of a box class to get it's color and compare that color to another box object.

Code:

if (Box1.GetColor()==Box2.GetColor())

A class can be used as a "black box". You don't need to know how meathods work only what they do an what they return or what private meathods/variables of the class do, you just need to know the class's interface and you can interact with that object.
Don't other use OOP, use it in situations where creating a class makes it easier to understand a problem or more convieniant. You don't have to make a class for everything.

Here is what I have so far for my game, in terms of object oriented programming

I have a class GameWorld, its responsiblities are only to handle coordinates of the game world and to communicate with the class Mobiles, mobiles sends coordinates to GameWorld...

There are multiple instances of Mobile, here is where the inheritence comes in, Mobiles is a shell, I'm either going it into 2 sections (NPC and Player mobiles) and then add more instances of Mobile::NPC (for different units and such) or, just create a mess of Mobiles::StarFighter Mobiles:: Player Mobiles::StarDefender....

But aren't Mobiles and Statics essentially just things inside of the GameWorld Class, so actually I guess it could go like this: GameWorld->Objects->Statics and Mobiles... Right? Then each static and mobile could pass collision detection info to objects and have it handle all that...

But technically, the only thing that needs to know collision information is mobiles... GameWorld doesn't necessarily need to know, right? So confused...

I understand inheritence, that part is easy, but like, how do classes use each other? How do they work together? theyre seperate objects....

Here are some examples:

(Note: don't let vectors or other STL containers and their notation scare you. A vector is similar to an array except it doesn't have a fixed size, so you can add as many elements to it as you want. Typically, you add another element using push_back(), which adds the element to the end of the vector. In addition, the notation tells you what's in the vector, e.g.:

vector<int> myInts;

The vector, which remember is like an array, can contain integers. Here's another one:

It seemed like a really interesting and easy to read book, although it's written for Java. If you note that an "interface" in Java is the same thing as a pure abstract class in C++(i.e. a class with all virtual functions and no definitions for the funtions), then you should be able to understand at least the first chapter if you want to take a look at it in the bookstore some time.

1) The designer first used straight inheritance, and the Duck base class implemented the speak() function to quack. The derived classes all inherited the same speak() function. The problem: not all Ducks speak() the same, RubberDuck's don't quack, they squeak.

2) The designer quickly made some changes to the Duck class to make speak() a virtual function and had each Derived class override speak() to get the proper noise for each species of Duck. Mallards would quack and RubberDuck's would squeak. The problem: if you anticipate having to alter the the noise each Duck makes in the future, you have to dig through every derived Duck class and make the specific changes to the overriding functions. If there are a lot of derived Duck classes, that can be a real chore to maintain.

3) The resulting design is one that extracts the methods that the programmer anticipates will require alteration in the future, i.e. speak(). That method was extracted from the Duck class and made into separate Quack and Squeak classes. Then each derived Duck class contains a member that is a Quack or Squeak object which represents the sound they make.

Future changes to the speak() methods will be much easier to maintain because they can be altered in the set of classes that represent the sounds ducks make, i.e. Quack and Squeak, and all of the Duck species that contain those objects will automatically reflect the changes. If you end up having 30 different noises that Duck's make, it will still be a pain to alter all 30 noises if that is required--but that's better than having to go through potentially 100's of derived Duck classes and changing the overridden speak() function in each one of them.

Quack and Squeak were also given a common base class Sound so that a Sound base class pointer could be used to point to both Quack and Squeak objects. Then, using the base pointer to call speak() results in the appropriate version of speak() being called (that's what "polymorphism" is all about!). The operateDuck() function demonstrates how that works.

the duck example is a good one. i have found that it is alot easier to demonstrate oop with the same type of small programs with several simple classes....

this professor i had once (who i think smoked a ton of crack before every class) anyhow though, he said that oop is like garbage and recycling in that you reduce, reuse, recycle... ?? yeh i dont know either.. but he went on...

reduce - keep your classes small and specialized, and the member functions specialized. if it looks like it is getting bloated, it probably is

reuse - you need to design with reuse, interuse in mind. just like in the duck example, inheritance and implicit casts(to base classes) are quite important for easy development

recycle - this really didnt have an answer. he just said it sounded good. someone asked him if it meant using delete, he said no, and that was the end of that..

hopefully you are as confused as I am now... lol.. the best way to figure it out is to make a bunch of classes that do nothing but print a little message and start creating derived classes, and creating functions that take a base class, make some virtual functions, play around with multiple inheri... etc... see what they do.. but do this with small classes... its too tempting to get into a big program and then you are just changing this and that until it works without really knowing what is going on....

Question, why do we virtualize functions? What does this accomplish? Forgive me for my noobness in C++.

Nevermind, answered that question:

A virtual function is a member function that you expect to be redefined in derived classes. When you refer to a derived class object using a pointer or a reference to the base class, you can call a virtual function for that object and execute the derived class's version of the function.

MSDN 4tw

Also, with this bit of code, are we just connecting Mallard to the parent class Duck?

1.When you vitualize functions that means the derivied class function with the same name will overwrite the base class function.

2. You are inheriting publicly from the Duck class which basically means you don't change any of the data hiding from the base class. If you were to say make it protected Duck. Only the class and derivied classes that derivied could call the public functions in the base class.

If you look at the output from the program, you will see that somehow the operateDucks() function was able to call the correct version of the speak() function for each pointer in the vector--even though all the pointers in the vector are Duck pointers.

Why didn't the function call the version of speak() in the Duck class everytime? The answer is polymorphism. If you delete the keyword virtual in front of the speak() function in the Duck class, see what happens.