Pada semester pertama kami diperkenalkan dengan konsep OOP seperti enkapsulasi, penyembunyian data, modularitas, pewarisan dan sebagainya melalui Java dan UML. (Java adalah bahasa pemrograman pertama saya)
Tidak satu pun dari mereka adalah konsep OOP. Mereka semua ada di luar OO, independen dari OO dan bahkan banyak ditemukan sebelum OO.
Jadi, jika Anda berpikir bahwa itulah yang dimaksud dengan OO, maka kesimpulan Anda benar: Anda dapat melakukan semua itu dalam bahasa prosedural, karena tidak ada hubungannya dengan OO .
Sebagai contoh, salah satu makalah mani tentang Modularitas adalah Pada Kriteria Untuk Digunakan dalam Sistem Penguraian menjadi Modul . Tidak disebutkan OO di sana. (Itu ditulis pada tahun 1972, saat itu OO masih merupakan ceruk yang tidak jelas, meskipun sudah berusia lebih dari satu dekade.)
Sementara Abstraksi Data penting dalam OO, itu lebih merupakan konsekuensi dari fitur utama OO (Messaging) daripada itu adalah fitur yang menentukan. Juga, sangat penting untuk diingat bahwa ada berbagai jenis abstraksi data. Dua jenis abstraksi data yang paling umum digunakan saat ini (jika kita mengabaikan "tidak abstraksi apa pun", yang mungkin masih digunakan lebih dari dua gabungan lainnya), adalah Abstrak Jenis dan Objek Data . Jadi, hanya dengan mengatakan "Menyembunyikan Informasi", "Enkapsulasi", dan "Abstraksi Data", Anda tidak mengatakan apa pun tentang OO, karena OO hanyalah satu bentuk Abstraksi Data, dan keduanya pada dasarnya berbeda secara mendasar:
- Dengan Tipe Data Abstrak, mekanisme abstraksi adalah sistem tipe ; itu adalah tipe sistem yang menyembunyikan implementasi. (Tipe sistem tidak harus statis.) Dengan Objects, implementasinya tersembunyi di balik antarmuka prosedural , yang tidak memerlukan tipe. (Misalnya, itu dapat diimplementasikan dengan penutupan, seperti yang dilakukan dalam ECMAScript.)
- Dengan Tipe Data Abstrak, instance dari ADT yang berbeda dienkapsulasi dari satu sama lain, tetapi contoh dari ADT yang sama dapat memeriksa dan mengakses perwakilan masing-masing dan implementasi pribadi. Objek selalu dienkapsulasi dari segalanya . Hanya objek itu sendiri yang dapat memeriksa perwakilannya sendiri dan mengakses implementasinya sendiri. Tidak ada objek lain , bahkan objek lain dengan tipe yang sama, instance lain dari kelas yang sama, objek lain yang memiliki prototipe yang sama, klon objek, atau apa pun yang bisa melakukan itu. Tidak ada .
Omong-omong, ini artinya di Java, kelas tidak berorientasi objek. Dua contoh dari kelas yang sama dapat mengakses representasi masing-masing dan implementasi pribadi. Oleh karena itu, instance dari kelas bukanlah objek, mereka sebenarnya adalah instance ADT. Java interface
, bagaimanapun, jangan memberikan berorientasi objek abstraksi data. Jadi, dengan kata lain: hanya instance dari interface yang objek di Java, instance dari class tidak.
Pada dasarnya, untuk tipe, Anda hanya dapat menggunakan antarmuka. Ini berarti jenis parameter metode dan konstruktor, jenis kembali metode, jenis bidang contoh, bidang statis, dan bidang lokal, argumen ke instanceof
operator atau operator gips, dan argumen jenis untuk konstruktor tipe generik harus selalu berupa antarmuka. Kelas dapat digunakan hanya secara langsung setelah new
operator, di tempat lain.
Sebagai contoh, untuk modularitas kita hanya dapat membagi program menjadi banyak program kecil yang melakukan tugas-tugas yang didefinisikan dengan baik yang kodenya terkandung dalam file terpisah. Program-program ini akan berinteraksi satu sama lain melalui input dan output yang terdefinisi dengan baik. File-file tersebut mungkin dilindungi (terenkripsi?) Untuk mencapai enkapsulasi. Untuk penggunaan ulang kode, kita dapat memanggil file-file itu kapan saja mereka dibutuhkan dalam program baru. Tidakkah ini menangkap semua OOP atau apakah saya kehilangan sesuatu yang sangat jelas?
Apa yang Anda gambarkan adalah OO.
Itu memang cara yang baik untuk berpikir tentang OO. Faktanya, itulah yang ada di pikiran para penemu OO. (Alan Kay melangkah lebih jauh: dia membayangkan banyak komputer kecil mengirim pesan satu sama lain melalui jaringan.) Apa yang Anda sebut "program" biasanya disebut "objek" dan alih-alih "panggilan", kita biasanya mengatakan "mengirim pesan" ".
Orientasi Objek adalah semua tentang Pesan (alias pengiriman dinamis ). Istilah "Object Oriented" diciptakan oleh Dr. Alan Kay, desainer utama Smalltalk, dan ia mendefinisikannya seperti ini :
OOP bagi saya hanya berarti pengiriman pesan, penyimpanan lokal dan perlindungan dan menyembunyikan proses negara, dan sangat mengikat semua hal.
Mari kita jabarkan:
- olahpesan ("pengiriman metode virtual", jika Anda tidak terbiasa dengan Smalltalk)
- proses negara seharusnya
- dipertahankan secara lokal
- terlindung
- tersembunyi
- sangat mengikat semua hal
Dari segi implementasi, olahpesan adalah panggilan prosedur yang terikat akhir, dan jika panggilan prosedur terlambat, maka Anda tidak dapat mengetahui pada waktu desain apa yang akan Anda panggil, sehingga Anda tidak dapat membuat asumsi tentang representasi konkret negara. Jadi, sebenarnya ini tentang pesan, keterlambatan mengikat adalah implementasi dari pesan dan enkapsulasi adalah konsekuensi dari itu.
Dia kemudian mengklarifikasi bahwa " Gagasan besar adalah 'pesan' ", dan menyesal telah menyebutnya "berorientasi objek" daripada "berorientasi pesan", karena istilah "berorientasi objek" menempatkan fokus pada hal yang tidak penting (objek ) dan mengalihkan perhatian dari apa yang benar-benar penting (olahpesan):
Hanya pengingat lembut bahwa saya bersusah payah di OOPSLA terakhir untuk mencoba mengingatkan semua orang bahwa Smalltalk bukan hanya BUKAN sintaks atau perpustakaan kelas, bahkan bukan tentang kelas. Saya minta maaf karena saya telah lama menciptakan istilah "objek" untuk topik ini karena itu membuat banyak orang untuk fokus pada ide yang lebih rendah.
Gagasan besarnya adalah "pesan" - itulah inti dari Smalltalk / Squeak (dan itu adalah sesuatu yang tidak pernah sepenuhnya selesai dalam fase Xerox PARC kami). Orang Jepang memiliki kata kecil - ma - untuk "apa yang ada di antara" - mungkin padanan bahasa Inggris terdekat adalah "pengantara". Kunci dalam membuat sistem yang hebat dan dapat ditumbuhkan jauh lebih banyak untuk merancang bagaimana modul-modulnya berkomunikasi daripada apa sifat dan perilaku internal mereka. Pikirkan internet - untuk hidup, itu (a) harus memungkinkan berbagai jenis ide dan realisasi yang melampaui standar tunggal dan (b) untuk memungkinkan berbagai tingkat interoperabilitas yang aman antara ide-ide ini.
(Tentu saja, hari ini, kebanyakan orang bahkan tidak fokus pada objek tetapi pada kelas, yang bahkan lebih salah.)
Pesan adalah hal mendasar bagi OO, baik sebagai metafora maupun sebagai mekanisme.
Jika Anda mengirim pesan kepada seseorang, Anda tidak tahu apa yang mereka lakukan dengannya. Satu- satunya hal yang dapat Anda amati, adalah respons mereka. Anda tidak tahu apakah mereka memproses pesan itu sendiri (yaitu jika objek memiliki metode), jika mereka meneruskan pesan tersebut ke orang lain (delegasi / proxy), jika mereka memahaminya. Itulah enkapsulasi tentang semua, itulah tujuan dari OO. Anda bahkan tidak dapat membedakan proksi dari yang asli, asalkan merespons bagaimana Anda mengharapkannya.
Istilah yang lebih "modern" untuk "pengiriman pesan" adalah "metode pengiriman dinamis" atau "panggilan metode virtual", tetapi itu kehilangan metafora dan berfokus pada mekanisme.
Jadi, ada dua cara untuk melihat definisi Alan Kay: jika Anda melihatnya berdiri sendiri, Anda mungkin mengamati bahwa pesan pada dasarnya adalah panggilan prosedur yang terikat akhir dan ikatan yang mengikat menyiratkan enkapsulasi, sehingga kita dapat menyimpulkan bahwa # 1 dan # 2 sebenarnya redundan, dan OO adalah tentang pengikatan akhir.
Namun, ia kemudian mengklarifikasi bahwa hal yang penting adalah olahpesan, sehingga kita dapat melihatnya dari sudut yang berbeda: olahpesan terlambat. Sekarang, jika olahpesan adalah satu - satunya hal yang mungkin, maka # 3 akan sepele benar: jika hanya ada satu hal, dan hal itu adalah keterlambatan, maka semua hal terikat terlambat. Dan sekali lagi, enkapsulasi mengikuti dari olahpesan.
Poin-poin serupa juga dibuat dalam On Understanding Data Abstraction, Revisited oleh William R. Cook dan juga Proposalnya untuk Definisi Modern tentang "Objek" dan "Berorientasi Objek" :
Pengiriman operasi yang dinamis adalah karakteristik penting dari objek. Ini berarti bahwa operasi yang akan dipanggil adalah properti dinamis dari objek itu sendiri. Operasi tidak dapat diidentifikasi secara statis, dan secara umum tidak ada cara untuk [tahu] operasi apa yang akan dijalankan sebagai tanggapan terhadap permintaan yang diberikan, kecuali dengan menjalankannya. Ini persis sama dengan fungsi kelas satu, yang selalu dikirim secara dinamis.
Di Smalltalk-72, bahkan tidak ada benda! Ada hanya aliran pesan yang mendapat diurai, ditulis ulang dan dialihkan. Pertama datang metode (cara standar untuk mengurai dan mengubah rute aliran pesan), kemudian datang objek (pengelompokan metode yang berbagi beberapa keadaan pribadi). Warisan datang jauh kemudian, dan kelas hanya diperkenalkan sebagai cara untuk mendukung warisan. Andaikata kelompok riset Kay sudah tahu tentang prototipe, mereka mungkin tidak akan pernah memperkenalkan kelas sejak awal.
Benjamin Pierce dalam Jenis dan Bahasa Pemrograman berargumen bahwa fitur penentu Orientasi Objek adalah Open Recursion .
Jadi: menurut Alan Kay, OO adalah tentang pesan. Menurut William Cook, OO adalah tentang pengiriman metode dinamis (yang benar-benar hal yang sama). Menurut Benjamin Pierce, OO adalah tentang Open Recursion, yang pada dasarnya berarti bahwa referensi-diri diselesaikan secara dinamis (atau setidaknya itu cara untuk memikirkannya), atau, dengan kata lain, pengiriman pesan.
Seperti yang Anda lihat, orang yang menciptakan istilah "OO" memiliki pandangan yang agak metafisik pada objek, Cook memiliki pandangan yang agak pragmatis, dan Pierce memiliki pandangan matematika yang sangat ketat. Tetapi yang penting adalah: filsuf, pragmatis, dan ahli teori semuanya setuju! Pesan adalah satu pilar OO. Titik.
Perhatikan bahwa tidak disebutkan pewarisan di sini! Warisan tidak penting untuk OO. Secara umum, sebagian besar bahasa OO memiliki beberapa cara implementasi digunakan kembali tetapi itu tidak harus menjadi warisan. Bisa juga berupa beberapa bentuk delegasi, misalnya. Bahkan, The Treaty of Orlando membahas delegasi sebagai alternatif pewarisan dan bagaimana berbagai bentuk pendelegasian dan pewarisan mengarah pada titik desain yang berbeda dalam ruang desain bahasa yang berorientasi objek. (Perhatikan bahwa sebenarnya bahkan dalam bahasa yang mendukung warisan, seperti Java, orang sebenarnya diajarkan untuk menghindarinya, sekali lagi menunjukkan bahwa itu tidak perlu untuk OO.)