Bagaimana saya bisa menjelaskan pemrograman berorientasi objek kepada seseorang yang hanya dikodekan dalam Fortran 77?

Ibu saya mengerjakan tesis kuliahnya di Fortran, dan sekarang (lebih dari satu dekade kemudian) perlu belajar c ++ untuk simulasi cairan. Dia mampu memahami semua pemrograman prosedural, tetapi tidak peduli seberapa keras saya mencoba menjelaskan objek kepadanya, itu tidak menempel. (Saya melakukan banyak pekerjaan dengan Java, jadi saya tahu bagaimana benda bekerja) Saya pikir saya mungkin menjelaskannya dengan cara yang terlalu tinggi, jadi itu tidak masuk akal bagi seseorang yang tidak pernah bekerja dengan mereka sama sekali dan tumbuh di usia pemrograman murni prosedural.

Apakah ada cara sederhana yang bisa saya jelaskan kepada mereka yang akan membantunya memahami?

Jawaban singkat: tidak.

Jawaban panjang: Tidak ada "cara sederhana" karena OOP jauh dari sederhana. Pemrograman prosedural adalah semua tentang "variabel" dan "jika kemudian kebagian". Semua yang lain adalah gula sintaksis, tetapi keempat hal tersebut adalah semua tentang pemrograman prosedural. Begitu Anda mendapatkannya, tidak ada yang bisa menghentikan Anda.

OOP adalah cara untuk mengatur variabel dan potongan kode. Berapa banyak pola yang ada untuk mendefinisikan OOP? 25? 30? Bahkan guru yang belajar OOP dari berbagai bahasa dan latar belakang tidak setuju dengan definisinya sendiri, jadi ... bagaimana bisa sederhana?

Saya tidak tahu bagaimana Anda sampai pada hal itu, tetapi karena ibu Anda memiliki pengalaman yang sama dengan saya, saya dapat memberi tahu Anda bagaimana saya sampai pada hal itu.

Saya pemrograman dalam C dalam proyek yang sangat besar. Itu tahun 1988. Banyak programmer mengatur modul dan perpustakaan, dengan kesulitan menghindari gangguan dalam pekerjaan lain dan menjaga pemisahan tugas yang baik.

Kami sampai pada "solusi" yang akan menempatkan semua data global yang saling terkait ke dalam struct, menempatkan dalam struct itu beberapa pointer fungsi di mana callback diperlukan. Kami menggeneralisasi dengan cara apa yang kami sebut io_mask(semacam kotak dialog mode tekstual) dan graphic_managerlain - lain.

Pada tahun 1996 Sangat mudah untuk menemukan bahwa struct tersebut dinamai "kelas" dan pointer fungsi tersebut digantikan oleh fungsi anggota dan fungsi virtual, atau dengan tautan ke objek lain (disebut perilaku) oleh programmer lain yang memperbarui proyek lama itu.

Saya mulai memahami OOP ketika saya mulai merasa perlu untuk itu: segregasi, polimorfisme, dan perilaku yang didefinisikan runtime.

Hari ini saya bekerja dengan OOP, tetapi saya tidak menganggapnya sebagai doktrin untuk melayani: hanya "idiom umum" (seperangkat ...) yang memungkinkan kita berbicara bersama tanpa perlu memberikan penjelasan dan deskripsi panjang sepanjang waktu . Bahkan, lebih merupakan "konvensi" daripada yang lain. Setelah semua, semua OOP lakukan adalah -again- "jika kemudian goto": itu hanya itu "berlapis-lapis". Karenanya abstraksi dan idiom atas idiom.

Abaikan mereka. Sampai dia tidak merasakan kebutuhan mereka bahkan tidak mencoba menjelaskan: dia akan merasakannya sebagai cara yang rumit untuk melakukan hal-hal sederhana. Dan dia benar ... sampai apa yang dia lakukan adalah - sebenarnya - sederhana.

Tidak ada yang akan berpikir untuk "mengatur meja" jika hanya ada empat hal di atas. Masuk akal ketika hal-hal di atas mulai saling mengganggu. Itulah saatnya OOP masuk.

Anda tidak perlu OOP untuk bekerja dengan C ++. Seluruh pustaka standar C ++ tidak dirancang dalam hal OOP (meskipun dapat bekerja sama dengannya), dan C ++ bukan Java.

Dalam semua pengalaman saya guru C ++ terburuk dan programmer C ++ adalah mereka yang berasal dari Jawa, mengajarkan semua prasangka mereka tentang semuanya bukan OOP, denaturasi bahasa seperti C ++ yang bukan (hanya) untuk OOP.

Izinkan saya menyarankan buku yang bagus bagi mereka yang ingin mendekati C ++: Dipercepat C ++ : itu akan membawa Anda ke dalam idiom C ++ tanpa berpura-pura mengikuti doktrin yang telah ditentukan.

Seorang teman lama mengklaim saya memiliki definisi terpendek yang dia tahu tentang pemrograman OO, dan saya menemukan bahwa itu berfungsi untuk beberapa orang (dan bukan untuk orang lain):

Pemrograman berorientasi objek adalah data dengan pendapat. Anda tidak memindahkan kursi, Anda meminta kursi itu untuk bergerak sendiri. Anda tidak mengurutkan daftar, Anda memintanya untuk mengurutkan sendiri (mungkin dengan sebuah petunjuk). Dll

Idenya adalah untuk membuat orang tersebut berpikir secara berbeda tentang bagaimana hal-hal dilakukan dalam program mereka.

Katakan padanya untuk memikirkan benda seperti benda di dunia nyata. Misalnya seluruh dunia dapat menjadi campuran pemrograman berorientasi objek (dalam C ++) dengan semacam pemrograman fungsional (mungkin dilakukan dalam bahasa dewa, Lisp).

Ambil sebuah objek, misalnya mesin pemotong rumput, ia memiliki atribut tertentu, dan dapat melakukan hal tertentu. (objek dan kelas)

Kemudian beri tahu dia tentang mesin pemotong rumput yang lebih baik yang merupakan perpanjangan dari mesin pemotong rumput yang sudah Anda miliki. Katakan padanya itu lebih baik tetapi masih dibangun di atas mekanisme yang sama (warisan).

Lalu katakan padanya tentang dirimu. Katakan padanya Anda kadang-kadang bisa menjadi ahli memotong rumput tetapi Anda sebenarnya adalah seorang programmer dan melakukannya untuk mencari nafkah. Ini seperti Anda bertindak sebagai dua entitas yang berbeda secara bersamaan. Ini adalah polimorfisme.

Pada saat dia mendapatkan ini, katakan padanya tentang bagaimana menerapkan hal-hal ini dalam bahasa yang harus dia pelajari (C ++).

Lalu katakan padanya, jika dia harus menulis simulasi dunia ini di dunia komputer, dia harus belajar bagaimana melakukannya.

Ketika dia tahu bagaimana mengubah pikirannya tentang dunia nyata menjadi kode program. dia akan belajar bagaimana memprogram dalam bahasa pemrograman berorientasi objek.

Saya telah beralih dari assembler dan COBOL ke Ruby.

Apa yang membantu saya pada awalnya sebenarnya mengabaikan konsep kelas membuat instance.

Mulai saja dengan kode. Memiliki kelas tetapi hanya memiliki metode tingkat kelas. Dalam metode banyak hal tentang parameter, variabel, kondisional, array, string, Boolean, dll. Hal-hal ini harus akrab.

Jadi pada titik ini kelas dapat dilihat sebagai hanya melayani tujuan sebagai tempat untuk meletakkan semua metode terkait Anda. Sebut saja wadah atau perpustakaan akan lebih akrab dengannya.

Jelas kode harus disegmentasi agar dapat dikelola sehingga Anda akan memiliki satu dari masing-masing area ini. Misalnya, untuk mengelola satu set program utilitas pada pc, Anda mungkin memiliki kelas kalkulator di mana Anda bisa meletakkan semua kode untuk kalkulator di satu tempat. Jika Anda hanya memiliki 1 kalkulator di komputer Anda, maka metode tingkat kelas sudah cukup.

Itu awal.

ok sekarang pertimbangkan fakta bahwa Anda ingin membuka banyak kalkulator dan mengubah bagaimana masing-masing terlihat dan di mana itu di layar. Jadi sekarang Anda tidak bisa hanya memiliki metode kalkulator seperti 'screen_location' karena Anda memiliki beberapa dari mereka dan setiap contoh memiliki lokasi sendiri ... setiap contoh ... ok, jadi kita perlu contoh.

Catatan: istilah saya berasal dari ruby ​​bukan c ++ jadi Anda mungkin perlu menerjemahkan.

Saya akan menjelaskannya dalam dua langkah, atau mungkin empat, tergantung pada seberapa besar Anda ingin membagi konsep Anda.

Langkah 1: Perkenalkan dia pada struktur. Ini adalah langkah yang cukup kecil dari tipe data Fortran ke struktur. Langkah 1a: pastikan dia memahami alokasi dan pointer memori dinamis.

Langkah 2: tambahkan prosedur yang hanya terkait dengan struktur itu. Langkah 2a: tambahkan warisan berdasarkan membangun struktur yang lebih besar yang "membungkus" struktur yang lebih kecil.

Bagi seorang programmer Fortran, faktor "wow" adalah karena banyak yang harus dilacak oleh kompiler. Ya. Itulah kompiler untuk ...

Jika dia melakukan tesisnya satu dekade yang lalu, dia mungkin menggunakan Fortan 90 atau 95, dalam hal ini untuk membicarakannya dalam hubungannya dengan tipe data yang diturunkan. Jika sudah lama dia menggunakan Fortran 77, maka perkenalkan dia dengan tipe data turunan di Fortran 90 dan kemudian bicarakan ...

Saya tidak akan membahas polimorfisme dan pewarisan, sampai setelah dia memahami enkapsulasi, karena mereka dapat dilihat sebagai kasus khusus dan ekstensi enkapsulasi. Saya mungkin akan memulainya dengan bahasa yang memungkinkan fungsi bebas atau kelas statis.

Begitu dia memahami struktur, saya pikir poin kunci berikutnya adalah mengenali bahwa pemrograman berorientasi objek berfungsi sebagai cara membatasi sekumpulan metode yang dapat dilewati sesuatu, ke sekumpulan metode yang sebenarnya dapat diterapkan pada hal itu. benda.

Dalam pemrograman non-objek-berorientasi, jika seseorang menggunakan tipe data yang terpisah untuk Tree dan LinkedList, orang harus menggunakan metode yang berbeda untuk menambahkan node ke masing-masing. Bahasa non-object-oriented akan umumnya mengomel jika salah satu mencoba untuk nama kedua metode AddItem, karena setiap nama yang diberikan hanya bisa merujuk ke salah satu metode, sehingga mengarah satu untuk membuat nama metode seperti AddTreeItem, AddLinkedListItem, RemoveTreeItem, dll seperti pendekatan sebuah karya, tapi sedikit jelek. Secara konseptual, metode AddTreeItemdan RemoveTreeItemtampaknya milik bersama, tetapi nama tidak seperti itu. Orang bisa menulis ulang nama-nama seperti TreeAddItem, TreeRemoveItem,LinkedListAddItem, dll. tetapi itu akan menempatkan banyak "redundant noise" pada awal setiap pemanggilan metode. Sebagian besar panggilan metode dalam program tipikal akan memiliki tiga informasi penting: (1) bagian mana dari kode sumber yang berisi metode; (2) metode mana dari bagian yang digunakan; (3) data apa yang sedang ditindaklanjuti? Dalam banyak kasus, tipe data yang ditindaklanjuti akan cukup untuk mengidentifikasi bagian kode mana yang dimiliki metode, sehingga bagian (1) di atas berlebihan. Lebih mudah untuk mengidentifikasi materi secara visual di awal pernyataan daripada materi di tempat lain, sehingga gaya pengkodean / penamaan seperti TreeAddItem(myTree, whatever)akhirnya menempatkan informasi yang paling tidak berguna di tempat utama.

Sebaliknya, menggunakan pemrograman berorientasi objek, seseorang akan secara efektif menamai metode sebagai Tree.AddItem, dll. Dan pernyataan seperti myTree.AddItem(whatever)akan menyebabkan kompiler mengatakan, pada dasarnya, "Hmm ... myTreeadalah tipe Tree, jadi kode ini harus dipanggil Tree.AddItem(). Tidak perlu untuk tentukan Tree.ketika memanggil AddItemkarena kompiler tahu jenisnya myTree. Secara konseptual, pernyataan seperti myTree.AddItem(whatever)ekuivalen dengan Tree.AddItem(myTree, whatever), dan beberapa bahasa berorientasi objek dapat mengizinkan kedua bentuk sebagai setara; pada kenyataannya, sebagian besar bahasa mengabaikan parameter pertama dari spesifikasi fungsi dan alih-alih memiliki metode yang didefinisikan dalam kelas seperti Treeimplisit mengambil parameter dari jenis Tree, dan menetapkan nama seperti this, self, atau Me.

Bahasa pemrograman berorientasi objek sering menyertakan berbagai fitur tambahan seperti pewarisan, fungsi virtual, dll. Yang sangat berguna dalam banyak aplikasi, tetapi bahkan tanpa fitur tersebut kemampuan untuk mengelompokkan fungsi sesuai dengan hal-hal yang dioperasikan sangat berguna.

Pemrograman berorientasi objek — dalam pengertian berorientasi kelas yang relevan di sini — adalah tentang menggabungkan representasi data dengan kode yang memanipulasinya. Masuk akal jika hal-hal berikut masuk akal:

• Coupling: mendefinisikan operasi di samping representasi data yang berfungsi

• Mengikat terlambat: memilih kombinasi representasi data dan perilaku saat runtime

• Enkapsulasi: memastikan bahwa data valid oleh konstruksi dan nantinya tidak akan divalidasi

Itu saja. Seperti halnya teknologi apa pun , pada intinya itu hanyalah kenyamanan, yang kemudian diikuti banyak perkembangan. Setelah Anda memahami dasar-dasarnya, sisanya mengikuti waktu.

Saya sarankan mengunduh BlueJ, bermain dengannya selama 20 menit kemudian membuatnya bermain dengannya selama 20 menit.

Cara memvisualisasikan kelas, antarmuka, dan warisan sangat jelas dan intuitif sehingga benar-benar memberi Anda pemahaman instan saat Anda mengimplementasikan sesuatu - apa saja.

Bahkan menunjukkan Anda secara langsung perbedaan antara kelas dan objek

Ini tidak akan memberikan wawasan mendalam ke dalam pola desain OO, tetapi akan memberikan gambaran konsep yang fantastis.

Saya ingin menambahkan kontribusi saya sebagai pengingat perbedaan antara paradigma pemrograman dan bahasa pemrograman yang mengimplementasikan paradigma ini.

Jadi, menurut saya, cara terbaik untuk menjelaskan orientasi objek dengan C ++ ke pengguna F77, adalah dengan melanjutkan secara bertahap:

Pertama, perkenalkan pengguna pada konsep orientasi objek dalam lingkungan yang sudah dikenal dengan menunjukkan padanya bagaimana mengembangkan struktur seperti objek di Fortran 77 - misalnya, lihat makalah seperti B. Patton "Object-oriented Fortran 77 (praktisi lihat) "SIGPLAN Fortran Forum 12, 2 (1993), hlm. 23-24, dan referensi di dalamnya.

Kemudian, buat korespondensi antara struktur tersebut dan kelas serta metode C ++.

Terakhir, diskusikan fitur-fitur tambahan yang dapat disediakan C ++ untuk memfasilitasi pemrograman OO.

Ketika saya pertama kali bermigrasi ke bahasa berorientasi objek dari pelatihan awal saya di Pascal, the '.' masalah adalah rintangan terbesar bagi saya juga. Butuh waktu bertahun-tahun untuk melupakannya.

Sebenarnya benar-benar tidak intuitif untuk variabel milik variabel lain, terutama ketika Anda terbiasa menganggap mereka sebagai petunjuk. Batu sandungan bagi saya adalah:

• Apa artinya untuk sesuatu yang pada dasarnya adalah sebuah pointer, untuk memiliki pointer lain menunjuk ke sana, yang memutuskan untuk hal yang berbeda dari pointer orangtua?

Momen aha bagi saya adalah ketika saya menyadari bahwa pointer level atas pada dasarnya hanya sebuah namespace.

Saya sarankan membuatnya untuk menulis banyak kode yang mengharuskannya untuk namespace fungsinya, idealnya tanpa menggunakan notasi titik untuk memulai. Kemudian buat dia untuk mencoba dan menulis ulang menggunakan notasi titik.

Melakukan latihan itu harus membuatnya mengatasi awal "Apa sihir ini?" rintangan.

Satu wawasan kunci yang telah membantu saya dalam menjelaskan sebelumnya adalah kenyataan bahwa Anda dapat memiliki banyak contoh kelas. Coba jelaskan dalam hal "gambar" atau "cetakan" dan "salinan" dan lihat apakah itu mengarah ke mana saja.