Re: Обєктно Орієнтовне програмування. Його взагалі можна зрозуміти?
я би йому радив не починати з власних класів, а з модифікації існуючих.
Ви не увійшли. Будь ласка, увійдіть або зареєструйтесь.
Ласкаво просимо вас на україномовний форум з програмування, веб-дизайну, SEO та всього пов'язаного з інтернетом та комп'ютерами.
Будемо вдячні, якщо ви поділитись посиланням на Replace.org.ua на інших ресурсах.
Для того щоб створювати теми та надсилати повідомлення вам потрібно Зареєструватись.
Український форум програмістів → Алгоритми та структури даних, технології → Обєктно Орієнтовне програмування. Його взагалі можна зрозуміти?
я би йому радив не починати з власних класів, а з модифікації існуючих.
я би йому радив не починати з власних класів, а з модифікації існуючих.
Анатолій
Патерни вам мабуть іще рано. Спробуйте спочатку найпростіші об'єкти, але щоб загалом програма була достатньо складною. А потім спробуйте зробити те саме на функціях.
Своє навчання викладу в цьому топіку, і собі на користь і форумчанам на контроль
саме по собі ООП це ніби просто, просто коли класси зрозумів, методи, але коли зібрати все до купи, то виникають питання, як отримати доступ від обєкту до того методу класу ...
саме по собі ООП це ніби просто, просто коли класси зрозумів, методи, але коли зібрати все до купи, то виникають питання, як отримати доступ від обєкту до того методу класу ...
Тому що ви не з того боку підходите до ООП. Спочатку накидайте приблизно, як має виглядати основний код, а потім розпишіть класи і методи, що вам знадобилися.
Анатолій, ви дуже доречно вибрали розділ, для цієї теми, та почали копати в правильному напрямку:
1. клас в ООП - це як набір скриптів для створення об’єктів - баз даних, таблиць, індексів;
2. об’єкт - це як рядок з даними у вже створеній таблиці;
3. приватні методи об’єкта - це як тригери в базі даних, які строго закріплені за певними таблицями;
4. методи класа та його можливості успадкування - це як процедури в базі даних, які здатні копіювати самих себе, та які мають скрипти для роботи з усією базою даних, а не лише з вибраними таблицями.
Ну а тепер подумайте: "Для чого взагалі потрібна база даних і для чого потрібні усі оці скрипти для неї?". Ми ж можемо створювати файлики та зберігати в них дані і без бази даних.
Отже який можна зробити висновок? ООП потрібне для створення складних структур даних, шляхом ізолювання окремих їх частин, а також для передачі їм методів, призначених для роботи з ними. І оскільки ООП призване працювати саме зі складними структурами даних (не обов’язково складними за розумінням, просто складнішими за найпростіші структури), то його архітектура дозволяє ще й копіювати та розширювати увесь цей описаний функціонал.
Відволікся, повернувся на форум, і бачу що другий мій пункт не вписується - об’єкт краще розглядати не як рядок у вже створеній таблиці, а взагалі як таблицю.
Індекси бази даних також під питанням, чи треба їх згадувати в цій аналогії... можливо їх краще порівняти з типами даних, але це вже трохи "притягнуте за вуха". Хоча якщо копати ООП глибше та докопати до композицій об’єктів, то можна знайти місце і базам даних як об’єктам, а також індексам як об’єктам.
Для простого пояснення об’єкта в ООП, достатньо поняття таблиці з її тригерами в базі даних.
Це не ООП, це АТД. Навіть без наслідування.
Це не ООП, це АТД. Навіть без наслідування.
Ви про таблицю? Я її порівнюю не з ООП, а з об’єктом в ООП.
koala написав:Це не ООП, це АТД. Навіть без наслідування.
Ви про таблицю? Я її порівнюю не з ООП, а з об’єктом в ООП.
А я кажу, що тут немає нічого з ООП: ані інкапсуляції (дані доступні для всіх процедур), ані наслідування (якщо треба розширити кількість даних для певних випадків - робиться додаткова таблиця з посиланням на рядок оригінальної), ані, тим більше, поліморфізма.
Так, між реляційними БД і ООП існують певні паралелі, але ці паралелі радше пов'язані із тим, що в обох концепціях є дані. На цьому спільне закінчується і починаються відмінності: БД дані зберігає, ООП їх змішує з кодом і "оживлює". Вже не кажу про те, що ООП не обмежується класами - наприклад, є ООП з прототипами, це в реляційних БД взагалі за межею уявлення.
А я кажу, що тут немає нічого з ООП: ані інкапсуляції (дані доступні для всіх процедур)
Ну можна створити декілька баз даних і роздати права на кожну із них.
... ані наслідування (якщо треба розширити кількість даних для певних випадків - робиться додаткова таблиця з посиланням на рядок оригінальної)
Аналогію з наслідуванням я навів у вигляді процедури, бо саме "схему класу" ми наслідуємо, а не дані. Процедура здатна породжувати нові процедури. Не зовсім зрозумів з вашого пояснення що ви мали на увазі про додаткову таблицю...
...ані, тим більше, поліморфізма.
Берете процедуру, зберігаєте її з новим іменем, дописуєте необхідні нові умови, дії.
Так, між реляційними БД і ООП існують певні паралелі, але ці паралелі радше пов'язані із тим, що в обох концепціях є дані. На цьому спільне закінчується і починаються відмінності: БД дані зберігає, ООП їх змішує з кодом і "оживлює". Вже не кажу про те, що ООП не обмежується класами - наприклад, є ООП з прототипами, це в реляційних БД взагалі за межею уявлення.
Думаю усі, навіть новачки, розуміють що це лише аналогія і 100% схожості немає.
Ну я б не сказав що в БД нема інкапсуаляції, ви ж не можете дізнатися які дані в табличці без попереднього підключення до бази даних?
Я б порадив вчити ООП з поліморфізму, а потім вже переходити в інкапсуляцію і наслідування.
Ну я б не сказав що в БД нема інкапсуаляції, ви ж не можете дізнатися які дані в табличці без попереднього підключення до бази даних?
Та елементарно - запуск процедури і повернення даних - це сама справжня інкапсуляція. Хто там знає де воно взялось і як воно взялось...
А чому назвали "обєктно орієнтовне програмування"
Назвали об'єктно орієнтованим, бо екземпляри всіх типів (класів, структур) можна узагальнено назвати об'єктами, без екземплярів (об'єктів) класи були б не потрібні. Початковою ідеєю ООП було саме створення об'єктів, а класи - це вже необхідність, яка випливає з того, що об'єкти, які мають однакові властивості, потрібно якось описати, такі описи і є класами, структурами.
Та ще ООП основане на : Інкапсуляції;Поліморфізмі;Спадкування. Мг-м, воно точно потрібне для того щоб програмувати?
Скажу так: ООП не є необхідністю, для того щоб створити програму, але коли отримаєте завдання на розробку великого проекту, то без ООП ваші пальці будуть в крові, або мозок носом витече, або життя не вистачить на завершення проекту.
Чи це просто теорія, і можна було б сказати ООП може бути просто гнукою мовою програмування. і забити на "Інкапсуляції;Поліморфізмі;Спадкування"
Вчіть ООП і досягнете "просвітлення"
Якщо реально хочете його вивчити попробуйте мову, в якій неможливо писати без ООП (C#, Java).
а давайте проведемо опитування, шо легче ассемблер чи ООП ?
Якщо реально хочете його вивчити попробуйте мову, в якій неможливо писати без ООП (C#, Java).
Погана порада. Будь-якою мовою можна писати імперативні програми, на зручність це майже не впливає - подумаєш, один зайвий рядок:
class MyApp {
public static void main(String[] args) {
//тут весь код
}
}
class MyApp { public static void main(String[] args) { //тут весь код } }
Так зазвичай і виглядають перші програми. Звичайно, якщо людина перед тим не вивчала ООП.
Так зазвичай і виглядають перші програми. Звичайно, якщо людина перед тим не вивчала ООП.
І коли вивчала - теж. Бо перші.
Я маю на увазі, перехід з процедурного на ООП. В мене "ух" коду було в:
public static void main(String[] args) {
...
}
Як то кажуть, набирав стрічку, за стрічкою...
а давайте проведемо опитування, шо легче ассемблер чи ООП ?
машинні коди
fed_lviv написав:Так зазвичай і виглядають перші програми. Звичайно, якщо людина перед тим не вивчала ООП.
І коли вивчала - теж. Бо перші.
Ну а для чого ООП в хеловорді чи сортуванні масиву методом бульбашок? Теорія ООП в принципі не пропонує юзабельних простих прикладів, що наочно демонструють переваги ООП (як я сказав вище, моделювання реальних об'єктів — не основне призначення ООП, і об'єкт з методом, що пише «кря-кря», моделлю качки є тільки з точки зору теоретиків ООП).