саме по собі ООП це ніби просто, просто коли класси зрозумів, методи, але коли зібрати все до купи, то виникають питання, як отримати доступ від обєкту до того методу класу ...

Анатолій, ви дуже доречно вибрали розділ, для цієї теми, та почали копати в правильному напрямку:
1. клас в ООП - це як набір скриптів для створення об’єктів - баз даних, таблиць, індексів;
2. об’єкт - це як рядок з даними у вже створеній таблиці;
3. приватні методи об’єкта - це як тригери в базі даних, які строго закріплені за певними таблицями;
4. методи класа та його можливості успадкування - це як процедури в базі даних, які здатні копіювати самих себе, та які мають скрипти для роботи з усією базою даних, а не лише з вибраними таблицями.

Ну а тепер подумайте: "Для чого взагалі потрібна база даних і для чого потрібні усі оці скрипти для неї?". Ми ж можемо створювати файлики та зберігати в них дані і без бази даних.

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

Це не ООП, це АТД. Навіть без наслідування.

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

Ну я б не сказав що в БД нема інкапсуаляції, ви ж не можете дізнатися які дані в табличці без попереднього підключення до бази даних?

Я б порадив вчити ООП з поліморфізму, а потім вже переходити в інкапсуляцію і наслідування.

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

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

Вчіть ООП і досягнете "просвітлення"
Якщо реально хочете його вивчити попробуйте мову, в якій неможливо писати без ООП (C#, Java).

Погана порада. Будь-якою мовою можна писати імперативні програми, на зручність це майже не впливає - подумаєш, один зайвий рядок:

class MyApp {
    public static void main(String[] args) {
        //тут весь код
    }
}

І коли вивчала - теж. Бо перші.

машинні коди