Represent individual object as a class?

Question

What is the best way to model the objects in my OOP program? I understand that the classes represent not particular objects but "groups"/"generalizations" of objects. But, I need to model individual objects that are significant in my domain for example Garfield and Snoopy below, which aren't a class of object at all but an object represented with a class?

Is this the proper way to model individual objects or am i missing something?

#include <iostream>

class Animal {
public:
    Animal(const char * name) : name(name) {};
private:
    const char * name;
};

class Dog : public Animal {
public:
    Dog(const char * name) : Animal(name) {};
private:
};

class Cat : public Animal {
public:
    Cat(const char * name) : Animal(name) {};
};

class Snoopy : public Dog {
public:
    Snoopy() : Dog("Snoopy") {};
};

class Garfield : public Cat {
public:
    Garfield() : Cat("Garfield") {};
};

int main() {
    Cat* garfield = new Garfield();
    delete garfield;
    return 0;
}

Thanks!

Answer 1

Classes define behavior.

If your Garfield and Snoopy don't have different behavior from other cats and dogs, they should most definitely not have their own class.

Consider whether you can't just create these special instances at the start of your program and pass them to where they're needed.

Answer 2

I understand that the classes represent not particular objects but "groups"/"generalizations" of objects.

Classes represent types of objects. They're part of the type system.

So if Garfield is a distinct type of cat, with different properties or logic than another cat, it might be a type, and you might represent that type with a class.

If Garfield is just a cat with a particular name - and maybe other specific values for normal cat-type attributes ... it's an instance of the same class.

eg.

class Garfield: public Cat {
  double lasagnaDeficit_; // property unique to Garfield
  ...
};

but if cats already have a favourite food, it might just be:

Cat *Garfield = new Cat("Garfield", /*favourite food*/ "Lasagna");

Answer 3

Uniqueness

You say in a comment that what makes makes Garfield different from Cat is that it's unique. That's not what a class does for you, though:

Cat* garfield = new Garfield();
Cat* garfieldTheSecond = new Garfield();
// you now have 2 Garfields

The important question is "In which way does the uniqueness matter?".

Concerning "identity", every instance of a class (every time you call new Cat) is already "unique". Even if you call new Cat("Garfield") twice, the 2 of them are apart entities; if you change data for one, the other won't be affected.

Concerning only using a name once... well first of all, if you only call new Cat("Garfield") once (and don't change names afterwards), only one cat with that name will ever exist. That's often enough already.

If you need to enforce name uniqueness, it's similar to real life. You need an "official place" that gives out cat names, and before they give out the name "Garfield", they need to check if they have already given it out. If no name should be used twice, they have to keep a list of names they give out.
In code, the quick and easy solution for this is to add a list of strings as a static variable in the class, and check against that during creation.

The horrible "Animal" example

The "Dog is a subclass of Animal" example is a staple of programming beginner tutorials. I absolutely hate it, because it completely misleads beginners. It pretends subclasses are this awesome everyday thing that can solve a lot of problems.

In reality, in the industry you rarely use it because you run into problems really quickly. At one job, we built up an application over 4 years and we used subclasses like, 3 times in there. You wouldn't make a subclass for Dog, let alone another one for a Dog with a certain name.

This is not a direct answer to your question, but before the horrible Animal example messes your understanding up like it did mine, I'd advise you to first read up on the problem by searching for "diamond problem", and then read up on the solution by searching for "composition over inheritance".

Answer 4

Interesting idea, actually. It is true that inheritance has fallen out of fashion in the past decades, except from stateless interfaces. But a separate type has one huge advantage in strongly typed languages like C++: It allows you to express a compile-time specification that something can only be done to Snoopy. If Snoopy were just a dog by another name you would always have to perform run time checks if you cuddle(Dog *d) him or put_him_on_snoopys_hut(Dog *d). Instead, you only cuddle(Snoopy *myDarlingSnoop), and there is no mistakin' in the dark.

Such compile time guarantees are the reason why we have a strongly typed language, and why it is a code smell to pass void pointers around in this strongly typed language.