Що за паніка? Візьміть себе в руки. Почніть з елементарного - хоча би зрозуміти те, що найчастіше Об'єкт у програмуванні - це по суті модель Об'єкту реального світу. Ось спробуйте словами описати об'єкт "Людина" (поки без коду, просто словами). Сам опис об'єкту - це клас. Тобто, коли ви зустрінете негра, то теоретично по опису ви зможете його віднести до класу "Людина", хоч сам цей негр буде якраз об'єктом. Це зрозуміло? А тоді спробуйте "унаслідувати" від "Людини" клас "Програміст". Ну, от спробуйте.

п.с. OOP та OOD - таки різні поняття, але вони й пов'язані між собою.

Спробую вам пояснити з іншого боку: в будь-якій живій мові є дві групи частин мови: назви і дії. Найпростіший варіант - іменники і дієслова, але ще є прикметники, дієприслівники і т.д., які якимось чином крутяться навколо цих двох частин.
Програмування на першому етапі мало фіксовані іменники (комірки пам'яті) та дієслова (команди процесора). Будь-яку ідею, щоб запрограмувати, треба було розкласти до рівня цих понять (тобто не "Петро дав Галі 2 яблука", а "значення комірки пам'яті, що зберігає кількість яблук Петра, зменшити на 2, а значення комірки пам'яті, що зберігає кількість яблук Галі, збільшити на 2")

SUB PetroAppleCount, 2
ADD HalyaAppleCount, 2

що для людини складно і неприродно.
Наступною ідеєю стали процедури - такі собі дієслова. Можна об'єднати кілька команд в одну логічну сутність (процедуру), яка буде втіленням певної ідеї. Програмування стало легшим: "з комірки пам'яті, що зберігає кількість яблук Петра, передати до комірки пам'яті, що зберігає кількість яблук Галі, 2 яблука".

GiveApples(var PetroAppleCount, var HalyaAppleCount, 2);

Звісно, все ще лишається проблема з іменниками (вони лишаються комірками), але, принаймні, ми вже не зможемо випадково відняти у Петра 2 яблука і додати Галі 4 - бо число 2 фігурує тут тільки 1 раз.
Звісно, питання, як бути з іменниками, лишалося. Виникли АТД - структури: можна зібрати кілька комірок (чи хоча б одну) і пояснити компілятору, що це не просто комірка, а щось інше, наприклад, кількість яблук. Тепер вже можна "передати з яблук Петра до яблук Галі 2 яблука"

GiveApples(Petro, Halya, 2);

що значно простіше для сприйняття, і не можна буде випадково передати петрові яблука до галиних груш.
Тут з'являються такі речі, як інкапсуляція і успадкування.
Має сенс запхати всі функції кудись ближче до об'єктів, щоб не переплутати, яку саме функцію ми застосовуємо, і заборонити доступ до даних (комірок пам'яті):

Petro.GiveApples(Halya, 2);//GiveApples - метод, що належить до типу Human, а Petro - змінна цього типу
Petro.AppleCount = Petro.AppleCount + 2;//помилка! немає доступу до даних!

- це інкапсуляція.
Успадкування дозволяє писати один раз функцію (чи давати опис даних) для кількох різних типів даних. Наприклад, якщо Галя вміє готувати пиріг з яблук, а Петро - ні, то можна зробити щось таке:

class Human//проголошення типу Human
{
  GiveApples( target, count ); //метод, що належить цьому типу
  //якісь ще дані і методи
}
class Cook extends Human//проголошення типу Cook - нащадка Human
{
  MakePie();//метод "приготувати пиріг"
  //якісь ще дані і методи
}
Human Petro;//Петро - просто людина
Cook Halya;//Галя - кухар
Petro.GiveApples(Halya,4);
Halya.GiveApples(Petro,2);//все добре, кухарі вмію робити все, що вміють і прості люди
Halya.MakePie();//працює!
Petro.MakePie();//помилка: прості люди не вміють готувати пироги

Ну і остання деталь, яка і робить ООП ООП - це поліморфізм. Нащадки можуть перевизначати методи предків, а програма під час виконання з'ясує, хто що і як робить. Наприклад, припустимо, що кухар перед тим, як комусь передати яблука, записує це до кухарського журналу. Тоді можна робити так:

function GiveBack( Human giver, Human taker )
{
  giver.GiveApples(taker,2);
  taker.GiveApples(giver,2);
}
Human Petro;
Cook Halya;
GiveBack( Petro, Halya );//Галя запише в журнал, що віддала 2 яблука Петрові, хоча програміст, що писав функцію GiveBack, міг взагалі не знати, що існує тип Cook

Що ж до OOD - то тут треба, окрім загального знання ООП, ще мати певний досвід розробки ООП-додатків і знати патерни. Невдалий вибір того, в якого саме об'єкта знаходиться метод, може дуже сильно попсувати нерви в майбутньому.

для мене  Об'єкт це виділення пам'яті в кучі з своїм пасьянсом і пошуком дівчат

Будинок - ваш обєкт. Вхідні параметри - люди, що в нього заходять. Методи - предмети будинку. Люди впливають на предмети. Люди, предмети будинку можуть бути видими/доступними або невидимими/недоступними для світу. Заховавши предмети, властивості будинку від вільного доступу іншим людям та від взаємодії їх з іншими предметами, нам простіше все впорядкувати в світі (програмі)

Ну, якщо так лякають:

То можна, для початку: "Объектно-ориентированный анализ и проектирование" - Бретт Маклафлин

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

Може тому, що потрібну всю систему переписати:), а коли є куча напрацювань, то тут уже проблема. Плюс чи будуть тоді програми написані раніше працювати на новій системі. Потрібно додаткову якусь прокладку писати для того щоб можна було викликати старі WindowsAPI. Адже тут вже не задача модернізації віндовз, а по суті нову систему з нуля потрібно зробити. Також хоч не хоч а система змушена працювати на найнижчому рівні напряму з апаратним забезпеченням...

P.S. По суті ООП система - це вже мабуть буде якась віртуальна машина на зразок JVM, адже для кожного фізичного елемента потрібне відповідне об'єктне відображення...

Щож панове всім дякую за розяснення, як завжди практика буде доброю панацеєю.
я ледь на грані утримував пояснення пана Коали, майже розумію що він він хоче сказати,
значить практика,
реалізую декілька паттернів класів обєктів та спробую Щоб Петро скуштував яблук Галі

розбирати Петю потрошки, по одному якомусь основному поняттю в день,
зараз в мене не виходить усвідомити зручність ООП

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