Bagaimana seseorang mengajar OO tanpa merujuk objek fisik dunia nyata? [Tutup]

Saya ingat pernah membaca di suatu tempat bahwa konsep asli di balik OO adalah untuk menemukan arsitektur yang lebih baik untuk menangani pengiriman data antara berbagai sistem dengan cara yang melindungi keadaan data tersebut. Sekarang itu mungkin parafrase yang buruk, tapi itu membuat saya bertanya-tanya apakah ada cara mengajar OO tanpa analogi objek (Sepeda, Mobil, Orang, dll.), Dan yang berfokus pada aspek olahpesan. Jika Anda memiliki artikel, tautan, buku, dll., Itu akan sangat membantu.

Konsep asli OO tidak ada hubungannya dengan apa OO hari ini. (Lihat Jadi, apa * yang * Alan Kay maksud dengan istilah "berorientasi objek"? ). Pemrograman berorientasi objek hari ini ADALAH tentang membuat objek seperti metafora sepeda dan rumah dan orang, dll. Saya sangat merekomendasikan tetap dengan ini karena tujuan metafora adalah untuk membantu orang memahami dengan menggunakan konsep yang sudah mereka pahami. Bantu mereka melihat korelasinya lalu bantu mereka melihat perbedaan MAKA terjun ke hal-hal yang lebih dalam tentang OO.

EDIT: OO hari ini adalah tentang membuat objek mandiri sepenuhnya yang sifat dan kemampuannya sepenuhnya / sebagian dijelaskan menggunakan berbagai metode (fungsi) dan atribut (referensi variabel dan konstanta AKA).

Anda dapat berbicara tentang konsep kopling dan kohesi. Objek harus terdiri dari atribut dan metode dengan kohesi tinggi dan kopling tinggi secara implisit. Mereka harus memetakan ke operasi granular paling tidak dan atribut yang diperlukan untuk sistem untuk bekerja. Mereka juga harus memenuhi keinginan untuk menjaga kode sekecil dan semudah mungkin, yaitu coding dengan pemeliharaan dan ekstensibilitas dalam pikiran.

Ini juga mencegah "ledakan objek", generalisasi berlebihan, dan pilihan metafora yang salah yang semuanya merupakan kesalahan umum.

Saya tidak akan fokus pada objek dunia nyata, dan saya juga tidak akan fokus pada pesan. Sebagai contoh, saya telah menggunakan grafik, di mana Anda ingin memiliki objek yang "tahu cara menggambar sendiri".

Jika Anda bekerja di C, misalnya, yang tidak memiliki OO bawaan, Anda mungkin merasa nyaman untuk menyimpan pointer ke fungsi di dalam objek data. Jika ya, berarti Anda memasuki OOP.

Saya tidak suka menyebut Alan Kay seolah-olah dia adalah Musa yang memberikan tablet. Sebaliknya, dia dilatih dalam matematika dan bio, saya percaya. Sebagai orang matematika, ia mungkin memiliki keakraban dengan Lambda Calculus, yang cukup abstrak, tidak terkait dengan perangkat keras. Dalam LC, Anda bisa mengatakan semuanya adalah "objek" - seperti angka 0 dan angka 1 adalah objek yang mengevaluasi hal-hal yang berbeda ketika diberi argumen. Itu mengarah ke Smalltalk dengan cukup baik. Gagasan "pesan" adalah agar kita dapat menghindari berbicara tentang perangkat keras. Anda bisa mengatakan ketika Anda memanggil suatu fungsi (atau metode suatu objek) Anda mengirimkannya pesan, dan ketika itu kembali, ia mengirimkan pesan kepada Anda (atau untuk kelanjutan Anda). Itu dikaitkan sebagai cara menggambarkan cara untuk berkomunikasi antara program yang berjalan secara tidak sinkron pada perangkat keras terpisah. Tidak apa-apa, tetapi untuk pemrograman biasa itu terbawa. Untuk mendapatkan nilai dari ide OOP, Anda tidak perlu menyangkal relevansi tugas konkret yang Anda coba lakukan, atau menolak konkret perangkat keras yang Anda jalankan. Saya pikir mengajar tentang OOP dalam hal analogi yang dibikin membuat orang berpikir tentang desain perangkat lunak terlalu banyak dalam hal struktur data, yang mengarah pada desain yang berlebihan, mengarah pada kode mengasapi dan masalah kinerja besar-besaran, sehingga saya harus menghabiskan waktu membersihkan ketika itu menjadi cukup buruk.

Saya akan mengklaim ada sedikit perbedaan dalam menggunakan objek fisik untuk contoh dan menggunakan objek non fisik sebagai contoh. Dalam kode mereka berdua memiliki bagian yang sama persis. Jika kita menggunakan contoh grafik dan mengajarkannya dengan Sphere, kubus, silinder, hampir sama dengan menggunakan bola, kotak, tiang.

Jadi untuk mengajarkannya tanpa menggunakan contoh fisik saya sarankan tidak menggunakan contoh sama sekali, tapi saya tidak melihat mengapa Anda tidak ingin contoh fisik jadi sikap saya pada topik adalah

Tidak, Anda tidak harus mengajarinya tanpa benda dunia nyata fisik

Saya tidak melihat bagaimana Anda dapat menghindari memulai dalam metafora dunia nyata, tetapi Anda tidak ingin tinggal di sana. Jika Anda melakukan OOP dengan benar, itu dengan cepat menjadi abstrak, tetapi pada tingkat pemahaman berikutnya, pelajar harus memahami objek sebagai objek.

Menariknya beberapa contoh favorit saya bukan benda fisik. Ambil contoh Rekening Bank. Setiap orang "mengetahui" mengapa setoran () dan penarikan () harus membebankan biaya layanan, daripada mengandalkan kode panggilan untuk mengubah nilai keseimbangan dan ingat untuk melepas biaya layanan. Bentuk pada layar dua kali lipat tidak berwujud, dan Stroustrup mengatakan kepada saya contoh klasik "Bentuk" adalah salah satu dari dua contoh OO tertua yang ia kenal, yang berasal dari 40 tahun yang lalu (yang lainnya adalah kendaraan, kini berusia 44 tahun.)

Yang penting adalah bahwa orang langsung memahami contoh Anda. Elevator membuat contoh yang baik hanya dengan orang-orang yang sudah terbiasa dengan elevator. Dll

Jika Anda berada dalam kelompok pemrograman, kumpulkan beberapa orang dan mulailah membahas bagaimana Anda akan saling memberi tahu untuk melakukan apa yang perlu dilakukan sistem. Ambil peran secara harfiah dalam sistem (Anda dapat melakukannya sendiri dengan hanya memainkan setiap peran, tetapi lebih mudah dengan sekelompok orang. Mainan membantu jika Anda melakukannya sendiri). Fokus pada apa yang setiap orang lakukan / akan lakukan, bukan pada data apa yang mereka miliki. Melakukan hal ini dengan orang-orang membantu fokus ini pada pesan dan peran karena orang cenderung mengingat apa yang mereka lakukan tetapi tidak pada data yang mereka miliki.

Perhatikan apa yang harus Anda minta untuk dilakukan satu sama lain, dan informasi apa yang perlu Anda lakukan. Bersikaplah melindungi data Anda sendiri, jika programmer lain meminta data Anda untuk sesuatu katakan tidak dan tanyakan kepadanya mengapa ia membutuhkannya (membantu enkapsulasi data).

Saya pikir pendekatan bottom-up / metal mungkin berguna. Pertama-tama jelaskan struct dan pointer C-style, untuk menunjukkan bagaimana data dapat disusun daripada hanya menggunakan primitif secara langsung. Kemudian jelaskan fungsi binding dan pointer yang terlambat. Kemudian jelaskan bahwa Anda dapat menggunakan ini untuk membangun objek, yang pada dasarnya adalah tumpukan data yang terenkapsulasi dengan baik dan pointer ke fungsi yang diperlukan untuk beroperasi pada data tersebut.

Penjelasan ini bertentangan dengan cara konvensional matematika / comp sci untuk mengajarkan konsep secara independen dari implementasi, tetapi perspektif itulah yang membuat saya (diakui seseorang dengan teknik, bukan comp sci, latar belakang) akhirnya mendapatkan OO.