Собаки й котики недостатньо абстрактні, щоб на них демонструвати ООП. А абстрактні поняття розлякують аудиторію, іншого пояснення я не можу придумати.

Я б порадив вчити ООП на абстракціях типу кіт і пес. Пес має вуха, і кіт їх має, але пес гарчить а кіт мявкає. З цьго виходить що метод voice буде реалізований по іншому.

#include <iostream>
using namespace std;

class Skotyna {
public:
    virtual void say() = 0;
    virtual ~Skotyna() {}
};

class Sobaka : public Skotyna {
public:
    void say();
};

void Sobaka::say() {
    cout << "Gau!" << endl;
}

class Kotiara : public Skotyna {
public:
    void say();
};

void Kotiara::say() {
    cout << "Miau!" << endl;
}

class Man : public Skotyna {
public:
    void say();
};

void Man::say() {
    cout << "Suka Nahui!" << endl;
}

int main() {
    Skotyna * pSkot = new Kotiara;
    pSkot->say();

    pSkot = new Man;
    pSkot->say();

    delete pSkot;
}

Справжнє призначення ООП — дати можливість маніпулювати структурно різними даними, використовуючи узагальнений зовнішній інтерфейс. Власне, прикладом елементів ООП в чистих процедурних мовах (таких як Сі чи Паскаль) є файли. З точки зору прикладної програми, яка працює з файлами, нема особливої різниці між файлом на жорсткому диску чи змінному носії, консоллю, інтерфейсом вводу-виводу іншої програми, приєднаної через пайп: будь-який «файл» підтримує одні й ті ж методи для читання і/або запису, внутрішня реалізація яких, проте, в кожному випадку відрізняється. Що це нам дає? Скажімо, програму, що виводить результат роботи на екран, можна легко переробити, щоб вона виводила цей результат у файл або на принтер — просто відкривши інший файл замість стандартного виводу. Без абстракції «файл», звичайно, можна обійтися — записувати дані в відеобуфер чи працювати з портами вводу-виводу дискового адаптера — але, крім того, що це для прикладного програміста складно, переписувати такий код, щоб змінити пристрій виводу, буде набагато довше.

Якщо для прораміста на процедурних мовах внутрішня реалізація файлів здебільшого лишається «чорною скринькою», то в ООП прийнято якраз і займатися розробкою подібних скриньок, для чого надається увесь необхідний інструментарій.

за написання  частини коду дякую, але варто було б дещо етичніше з іменами

Якщо розглядати/вивчати парадигму ООП, то здається було б логічно задати питання за місце ООП а сфері програмування;
переглянув то їх там з десяток буде...
точніше якщо наразі вона(парадигма ООП) популярна в неї більше переваг чим недоліків

то чи можна було б стверджувати, що ООП це результат еволюції програмування від машинного коду

чи все ж варто сказати що кожна парадигма програмування розвивається паралельно?

І таке змістовне питання: - Які на Ваш погляд суттєві переваги ООП порівняно з іншими, а які є недоліки ООП?

Наприклад зустрів ось такий висновок:

чи навіть таке сочне яскраве переконання зручності ООП

Хоча просто можна сказати ООП то зручно і його варто вивчити, ... а з часом буде популярне, скажімо аспектно-орієнтовне (чи яка там парадигма виграє еволюційний тендер)

propeller paralax не чули ?

ну думаю збоченці найдуться, або вже є

та  і AVR теж є  на С++

Працюю над власними нотатками

І хотів би створити гарний наочний малюнок, наприклад, по-кроково розглядати поняття ООП,

чи підійшов би за змістом ось такий малюнок?
На даному малюнку хотів би представити поняття "клас та обєкт", та здається взаємозв'язки (обмін інформацією) між обєктами програми, напевно ж чуть варто було б по іншому вказати.
Так як $Some_object_name_A = new A; - це просто створення* нового об'єкту певного класу, а обмін інформацією між обєктами все ж вже в подальших кроках програми.

- Можливо за даним малюнком  якийсь суттєвий елемент варто було б вказати?

Клас - то насправді взагалі необов'язкове поняття в ООП, багато мов використовують замість класів прототипи. Різниця в тому, що прототипи об'єктів можна змінювати динамічно.
Якщо хочете показати стосунки між класами та об'єктами, то створіть хоча б один клас-нащадок (наприклад B extends A) і напишіть, що $Some_object_name_B є об'єктом класів A і B одночасно.
Крім того, ви не розділяєте проголошення і створення. Так, $objectA - проголошення, а = new A(); - створення. Створений об'єкт не прив'язаний до своєї змінної:

$objectA = new A();
$otherA = objectA;//тепер $objectA і $otherA вказують на один і той самий об'єкт
$objectA = new A();//тепер $objectA вказує вже на інший об'єкт класу A, 
//а $otherA вказує на той об'єкт, що первинно був $objectA