Як я можу пояснити об'єктно-орієнтоване програмування тому, хто кодується лише у Fortran 77?

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

Чи є якийсь простий спосіб я пояснити їх їй, який допоможе їй зрозуміти?

Коротка відповідь: ні.

Довга відповідь: "Не існує простого способу", оскільки OOP далеко не простий. Процедурне програмування стосується "змінних" і "якщо потім перейти". Все інше - синтаксичний цукор, але ці чотири речі - це все, що стосується процедурного програмування. Як тільки ви їх отримаєте, ніщо не може зупинити вас.

OOP - це спосіб організації змінних та фрагментів коду. Скільки моделей існує для визначення OOP? 25? 30? Навіть викладачі, які вивчали ООП з різних мов та походження, не згодні з його власним визначенням, тож ... як це може бути просто?

Я не знаю, як ви дійшли до цього, але оскільки у вашої матері є подібний досвід до мого, я можу вам сказати, як я прийшов до цього.

Я програмував на C в дуже великому проекті. Це було 1988. Багато програмістів організовували модулі та бібліотеки, утруднюючись уникнути втручання в інші робочі місця та зберігати належну сегрегацію обов'язків.

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

У 1996 році було дуже легко виявити, що ці структури були названі "класами", а ті функціональні вказівники замінені функцією-членом і віртуальними функціями, або посиланнями на інші об'єкти (звані поведінкою) іншими програмістами, які відновили цей старий проект.

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

Сьогодні я працюю з ООП, але я не вважаю це доктриною, яка повинна слугувати: просто "загальна ідіома" (набір ...), яка дозволяє нам говорити разом без необхідності постійно надавати довгі пояснення та описи. . Насправді, більше "конвенція", ніж будь-що інше. Зрештою, все, що робить OOP, це -again- "if then goto": це просто робиться "багатошаровим". Звідси абстракція та ідіоми над ідіомами.

Ігноруйте їх. Поки вона не відчує потреби в них, навіть не намагайся пояснити: вона буде відчувати їх так само, як складний спосіб робити прості речі. І вона права ... поки те, що вона робить, - це фактично просто.

Ніхто не подумає "організувати стіл", якщо на вершині всього чотири речі. Має сенс, коли речі зверху починають заважати одна одній. Настав час прийому ООП.

Для роботи з C ++ вам не потрібен OOP. Вся стандартна бібліотека C ++ не розроблена в плані OOP (хоча вона може співпрацювати з нею), а C ++ - не Java.

З мого досвіду найгірші C ++ викладачі та програмісти на C ++ - це ті, хто походить з Java, навчаючи всі свої забобони щодо всього, що не є OOP, денатурація такою мовою, як C ++, яка не є (тільки) для OOP.

Дозвольте запропонувати гарну книгу для тих, хто хоче підійти до C ++: Прискорений C ++ : це введе вас у ідіоми C ++, не претендуючи на дотримання заздалегідь визначеного вчення.

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

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

Ідея полягає в тому, щоб змусити людину по- різному думати про те, як все робити в межах програми.

Скажіть їй думати про предмети, як предмети в реальному світі. Наприклад, весь світ може бути поєднанням об'єктно-орієнтованого програмування (на C ++) з деяким функціональним програмуванням (можливо, зробленим мовою бога, Лісп).

Візьмемо предмет, наприклад газонокосарку, він має певні атрибути, і він може зробити певну річ. (об’єкт і клас)

Тоді розкажіть їй про кращу газонокосарку, яка є продовженням газонокосарки, яку ви вже маєте. Скажіть їй, що краще, але все-таки будується на тому ж механізмі (успадкування).

Тоді розкажи їй про себе. Скажіть їй, що іноді ви можете стати фахівцем з газонокосіння, але ви насправді програміст і займаєтесь на життя. Це як ви виступаєте одночасно двома різними сутностями. Це поліморфізм.

До того моменту, коли вона це отримає, розкажіть їй про те, як реалізувати ці речі мовою, яку вона повинна вивчити (C ++).

Тоді скажіть їй, якщо їй доведеться написати моделювання цього світу в світі комп'ютерів, їй доведеться навчитися це робити.

Коли вона знає, як перетворити свої думки про реальний світ у програмний код. вона б навчилася програмувати об'єктно-орієнтованою мовою програмування.

Я пройшов шлях від асемблера та COBOL до Ruby.

Що мені допомогло спочатку було насправді ігнорувати концепцію створення класів екземплярів.

Почніть тільки з коду. Майте клас, але просто використовуйте методи рівня класу. У методах багато матеріалів стосується параметрів, змінних, умовних умов, масивів, рядків, булевих і т.д. Цей матеріал повинен бути знайомий.

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

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

Це початок.

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

Примітка: мої умови від рубіну не з ++, тому вам може знадобитися перекласти.

Я б пояснив це в два етапи, а може, і в чотири, залежно від того, наскільки ви любите розділяти свої концепції.

Крок 1: Познайомте її зі структурами. Це досить невеликий крок від типів даних Fortran до структур. Крок 1a: переконайтеся, що вона розуміє динамічне розподілення пам'яті та покажчики.

Крок 2: додайте процедури, пов'язані лише з цими структурами. Крок 2а: додайте спадщину на основі побудови більших структур, які "обгортають" менші структури.

Для програміста Fortran фактором "вау" буде те, що компілятор має багато чого слідкувати. Так. Ось для чого компілятори ...

Якщо вона робила дисертацію десятиліття тому, вона, ймовірно, використовувала Фортан 90 або 95, і в цьому випадку мова йде про це стосовно відносно похідних типів даних. Якщо давно вона використовувала Fortran 77, то познайомте її з похідними типами даних у Fortran 90, а потім поговоріть про це ...

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

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

У не об’єктно-орієнтованому програмуванні, якщо використовується окремі типи даних для Дерева та LinkedList, доведеться використовувати різні методи для додавання вузла до кожного. Номери об'єктно-орієнтовані мови , як правило , пронизливий крик , якщо один спробував назвати обидва методи AddItem, так як будь-яке ім'я може відноситися тільки до одного способу, що призводить один для створення імен методів , як AddTreeItem, AddLinkedListItem, RemoveTreeItemі т.д. Такий підхід працює, але це трохи потворний. Концептуально методи AddTreeItemі, RemoveTreeItemздається, належать разом, але назви не сортуються таким чином. Можна було б переписати імена , як TreeAddItem, TreeRemoveItem,LinkedListAddItemтощо, але це може спричинити багато "зайвого шуму" на початку кожного виклику методу. Переважна більшість викликів методів у типовій програмі матиме три основні відомості: (1) який розділ вихідного коду містить метод; (2) який із методів у розділі використовується; (3) над якою частиною даних застосовується дія? У багатьох випадках тип даних, що застосовується, буде достатнім для визначення того, до якого розділу коду належить метод, тому частина (1) вищезазначеного є зайвою. Візуально ідентифікувати матеріал на початку висловлювання легше, ніж матеріал в іншому місці, тому стиль кодування / іменування, як-от в TreeAddItem(myTree, whatever)кінцевому підсумку, в кінцевому місці ставить найменш корисну інформацію.

На противагу цьому, використовуючи об'єктно-орієнтоване програмування, можна ефективно називати методи як Tree.AddItemі т.д., а висловлювання на зразок myTree.AddItem(whatever)викликає компілятор сказати, по суті, "Хм ... myTreeмає тип Tree, тому цей код повинен викликати Tree.AddItem(). Це не потрібно вкажіть Tree.при виклику, AddItemоскільки компілятор знає тип myTree. Концептуально такий вираз, як myTree.AddItem(whatever)еквівалент Tree.AddItem(myTree, whatever), і деякі об'єктно-орієнтовані мови можуть дозволити обидві форми як еквівалентні; насправді більшість мов опускають перший параметр із специфікації функції і замість цього мають методи, визначені в класі , як Treeнеявно приймають параметр типу Tree, і привласнити йому ім'я , як this, selfабо Me.

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

Об'єктно-орієнтоване програмування - у сенсі, орієнтованому на клас, що стосується тут - стосується з'єднання представлення даних з кодом, який ним маніпулює. Це має сенс, якщо такі речі мають сенс:

• З'єднання: визначення операції поряд із поданням даних, над якими вона працює

• Пізня прив'язка: вибір комбінації подання даних та поведінки під час виконання

• Інкапсуляція: забезпечення того, що дані є достовірними при побудові та згодом не будуть визнані недійсними

Це все. Як і будь-яка технологія, в основі її просто зручність, з якої згодом випливало багато розробок. Після того, як ви зрозумієте основи, решта слід за часом.

Я б запропонував завантажити BlueJ, пограти з ним протягом 20 хвилин, а потім зіграти з нею протягом 20 хвилин.

Те, як вона візуалізує класи, інтерфейси та успадкування, настільки очевидна та інтуїтивна, що вона справді дає вам миттєве розуміння, коли ви реалізуєте щось - що завгодно.

Він навіть показує вам безпосередньо різницю між класом і об'єктом

Це не дасть глибокого розуміння моделей дизайну ОО, але дасть фантастичний огляд концепцій.

Я хотів би додати свій внесок як нагадування про відмінність між парадигмами програмування та мовами програмування, які реалізують ці парадигми.

Отже, на мою думку, найкращим способом пояснити орієнтацію об'єкта з C ++ на користувача F77 було б поступово діяти:

По-перше, ознайомте користувача з поняттям орієнтації на об'єкт у звичній обстановці, показавши їй, як розвивати об’єктоподібні структури у Fortran 77 - наприклад, ознайомтеся з документами на зразок Б. Паттона "Об'єктно-орієнтований Fortran 77 (практик погляд) "SIGPLAN Fortran Forum 12, 2 (1993), стор 23-24, та посилання на них.

Потім встановіть відповідність між цими структурами та класами та методами C ++.

Нарешті, обговоріть додаткові функції, які C ++ може надати для полегшення програмування ОО.

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

Насправді насправді неінтуїтивно відноситись до іншої змінної, особливо коли ти звик думати про них як про вказівники. Каменем спотикання для мене було:

• Що означає для чогось, що в основному є вказівником, мати інший вказівник, який вказує на нього, що вирішує іншу річ, ніж батьківський вказівник?

Для мене був момент ага, коли я зрозумів, що вказівник верхнього рівня - це просто простір імен.

Я запропонував би змусити її написати купу коду, який вимагає від неї простору імен її функцій, в ідеалі, не використовуючи позначення крапок для початку. Тоді змусьте її спробувати і переписати її, використовуючи крапкові позначення.

Виконуючи цю вправу, слід перемогти її над початковою "Що це за чаклунство?" перешкода

Одне ключове розуміння, яке допомогло мені пояснити раніше, - це той факт, що ви можете мати кілька примірників класу. Спробуйте пояснити, що з точки зору "малюнків" чи "форм" та "копій", і подивіться, чи це веде кудись.