OO (Object Oriented) design is based on the premise that entities are "objects" and things that happen result from the way objects behave and interact with each other. A "class" is a category of object, and each object belongs in a category (in OO-speak, "object belongs in a category" is turned around as "each object is an instance of a class"). Let's say we have two ducks, named for sake of discussion "Donald" and "Daisy"; in an OO model, the one described as "Donald" would be a different object from the beat called "Daisy", but both are still ducks.
Now, in C++, a class is (in computer-speak) a data structure. It defines attributes (eg legs, wings, webbed feet, a bill, etc) that every duck has. And both "Donald" and "Daisy" would be different ducks: they don't share legs, wings, feet, bill, or other characteristics with each other (and, in fact, their wings may be objects in their own right, if we model it that way, and the duck would be described in OO-speak as "an aggregate of wings, feet, ..."). And the duck has behaviour (eg flying, courtship behaviour, swimming, quacking, etc). Some of those behaviours involve interaction with other objects (eg courting involves an interaction with another duck, swimming involves interaction with a body of water), so if we're defining a Duck class we might (depending on what our application is to do) define a Duck as a C++ class;
class Duck
{
public:
Duck(const std::string &myname, bool is_male) : name(myname), male(is_male) {};
void Swim(BodyOfWater &);
void Court(Duck &object_of_affection);
Location Position() {return position;};
void SetPosition(Location l) {position = l;};
private:
std::string name;
bool male;
Location position; // Location may be represented as a class too
// other attributes representing characteristics of the duck
void DoCourtshipDance(Duck &object_of_affection);
// and implementatiuon of some behaviour internally
}; where the member function Duck() is invoked when an instance of Duck is created, Swim() implements an interaction between a duck and a body of water, and Court() implements behaviour of a drake (male duck) when it sees an eligible female.
For example, one implementation of Court() might be
void Court(Duck &object_of_affection)
{
if (male && !object_of_affection.male) return; // drakes court ducks
DoCourtshipDance(object_of_affection);
} and we might use this in a simple simulation as;
int main()
{
Duck donald("Donald", true); // a drake
Duck daisy("Daisy", false); // a female duck
Lake lake; // a body of water
bool carry_on = true;
// place donald and daisy in some random positions in the lake
while (carry_on)
{
donald.swim();
daisy.swim();
if (Distance(donald.Position(), daisy.Position()) < 20) // daisy < 20 metres from donald
{
donald.Court(daisy); // donald is one desperate duck
carry_on = false;
}
}
return 0;
}
The key in any object-oriented design is to define your categories of objects, what attributes they have, and how they interact with each other. And then create various objects and make them interact. It is not necessary to be comprehensive. For example, the attributes and behaviour a duck has in a kids game will be significantly different from the attributes and behaviour we'd want it to have in a program for managing a duck farm.
One other characteristic of classes is that one class can be a specialised form of another. For example, in the above, a Lake is a specialised type of "BodyOfWater". This sort of relationship is represented in C++ classes using inheritence;
class BodyOfWater
{
// define generic behaviour and attributes of a BodyOfWater
}
class Lake : public BodyOfWater
{
// define specific behaviour and attributes of Lake
// these may be inherited directly from BodyOfWater
// eg size, location, etc
// or may not (eg number of catfish it contains)
} Similarly, if we choose to model it that way, the Duck class might be derived from a class named WaterBird, which might in turn be derived from Bird. A Bird would represent attributes and behaviour of all birds, WaterBird would represent (well) birds that tend to live around water, etc.