Sejarah OOP yang Terlupakan

Sebagian besar paradigma pemrograman yang kita gunakan saat ini pertama kali dipelajari secara matematis pada 1930-an menggunakan ide-ide kalkulus lambda dan mesin Turing, yang merupakan varian dari model komputasi universal (ini adalah sistem formal yang dapat melakukan perhitungan tujuan umum). Tesis Church-Turing menunjukkan bahwa kalkulus lambda dan mesin Turing secara fungsional setara. Yaitu, kita berbicara tentang fakta bahwa segala sesuatu yang dapat dihitung menggunakan mesin Turing juga dapat dihitung menggunakan lambda calculus, dan sebaliknya.



Ada kesalahpahaman umum bahwa mesin Turing dapat menghitung semua yang dapat dihitung. Ada kelas masalah (misalnya, masalah berhenti ) yang dapat dihitung menggunakan mesin Turing hanya untuk beberapa kasus. Ketika kata "computably" digunakan dalam teks ini, itu berarti "computably oleh mesin Turing".

Kalkulus Lambda menunjukkan pendekatan penerapan fungsi untuk perhitungan secara top-down. Mesin Turing tape adalah pendekatan imperatif (langkah-demi-langkah) untuk komputasi, yang diterapkan berdasarkan bottom-up.

Bahasa pemrograman tingkat rendah, seperti kode mesin atau assembler, muncul pada 1940-an, dan, pada akhir 1950-an, bahasa tingkat tinggi populer pertama muncul yang menerapkan pendekatan fungsional dan imperatif. Jadi, dialek bahasa Lisp masih banyak digunakan, di antaranya Clojure, Skema, AutoLisp dan sebagainya. Pada tahun lima puluhan, bahasa seperti FORTRAN dan COBOL muncul. Mereka adalah contoh dari bahasa tingkat tinggi yang sangat penting yang masih hidup. Meskipun harus dicatat bahwa bahasa keluarga C, di sebagian besar wilayah, menggantikan COBOL dan FORTRAN.

Akar pemrograman imperatif dan fungsional terletak pada matematika formal komputasi, mereka muncul di depan komputer digital. Pemrograman Berorientasi Objek (OOP) datang kemudian, itu berasal dari revolusi pemrograman struktural yang terjadi pada tahun enam puluhan dan tujuh puluhan abad terakhir.

Objek pertama yang saya tahu digunakan oleh Ivan Sutherland dalam aplikasi yang ditakdirkan Sketchpad, dibuat antara 1961 dan 1962, yang ia gambarkan dalam karya ini pada 1963. Objek adalah karakter grafis yang ditampilkan pada layar osiloskop (mungkin ini adalah pertama kalinya dalam sejarah menggunakan monitor komputer grafis) yang mendukung warisan melalui delegasi dinamis, yang disebut Ivan Sutherland sebagai "tuan" dalam karyanya. Objek apa pun bisa menjadi objek master, instance tambahan objek itu disebut "kejadian". Ini membuat sistem Sketchpad menjadi pemilik yang pertama dari bahasa pemrograman terkenal yang menerapkan pewarisan prototipe.

Bahasa pemrograman pertama, umumnya dikenal sebagai "berorientasi objek," adalah bahasa Simula, yang spesifikasinya dikembangkan pada tahun 1965. Seperti Sketchpad, Silmula disediakan untuk bekerja dengan objek, tetapi juga termasuk kelas, pewarisan berbasis kelas, subkelas, dan metode virtual.

Metode virtual adalah metode yang didefinisikan dalam kelas yang dirancang untuk didefinisikan ulang oleh subclass. Metode virtual memungkinkan program untuk memanggil metode yang mungkin tidak ada pada saat kode dikompilasi, dengan menggunakan pengiriman dinamis untuk menentukan metode tertentu yang harus dipanggil selama eksekusi program. JavaScript memiliki tipe dinamis dan menggunakan rantai delegasi untuk menentukan metode mana yang harus dipanggil. Akibatnya, bahasa ini tidak perlu memperkenalkan konsep metode virtual kepada pemrogram. Dengan kata lain, semua metode dalam JavaScript menggunakan pengiriman pada saat run-time, akibatnya, metode dalam JavaScript tidak perlu dinyatakan "virtual" untuk mendukung fitur ini.

Opini ayah OOP tentang OOP

"Saya menciptakan istilah" berorientasi objek, "dan saya dapat mengatakan bahwa saya tidak bermaksud C ++." Alan Kay, Konferensi OOPSLA, 1997.

Alan Kay menciptakan istilah "pemrograman berorientasi objek", mengacu pada bahasa pemrograman Smalltalk (1972). Bahasa ini dikembangkan oleh Alan Kay, Dan Ingles dan karyawan lain dari Xerox PARC Research Center sebagai bagian dari proyek perangkat Dynabook. Smalltalk lebih berorientasi objek daripada Simula. Dalam Smalltalk, semuanya adalah objek, termasuk kelas, bilangan bulat, dan blok (penutup). Implementasi awal bahasa, Smalltalk-72, tidak memiliki kemampuan untuk subkelas. Fitur ini muncul di Smalltalk-76.

Sementara Smalltalk mendukung kelas-kelas, dan, sebagai akibatnya, subclassing, Smalltalk tidak menempatkan ide-ide ini di garis depan. Itu adalah bahasa fungsional yang dipengaruhi Lisp seperti halnya Simula. Menurut Alan Kay, memperlakukan kelas sebagai mekanisme penggunaan kembali kode adalah sebuah kesalahan. Industri pemrograman menaruh perhatian besar pada penciptaan subclass, mengalihkan dari manfaat nyata pemrograman berorientasi objek.

JavaScript dan Smalltalk memiliki banyak kesamaan. Saya akan mengatakan bahwa JavaScript adalah pembalasan Smalltalk di dunia karena salah paham konsep OOP. Kedua bahasa ini mendukung fitur berikut:

• Benda
• Fungsi dan penutupan kelas satu.
• Tipe dinamis.
• Mengikat terlambat (fungsi dan metode dapat diganti selama eksekusi program).
• OOP tanpa sistem pewarisan berbasis kelas.

"Saya menyesal telah menemukan istilah" objek "sejak lama untuk fenomena ini, karena penggunaannya mengarah pada fakta bahwa banyak orang memberikan kepentingan utama pada sebuah ide yang tidak sepenting yang utama. Ide utamanya adalah perpesanan. ” Alan Kay

Dalam korespondensi email 2003, Alan Kay mengklarifikasi apa yang ada dalam pikirannya ketika dia menyebut Smalltalk "bahasa berorientasi objek."

"Bagi saya, OOP hanya berarti pengiriman pesan, penyimpanan lokal, dan perlindungan, dan status persembunyian, dan sangat terlambat mengikat." Alan Kay

Dengan kata lain, sesuai dengan ide-ide Alan Kay, bahan OOP yang paling penting adalah sebagai berikut:

• Olahpesan
• Enkapsulasi.
• Tautan dinamis.

Penting untuk dicatat bahwa Alan Kay, orang yang menemukan istilah "OOP" dan membawanya ke massa, tidak menganggap warisan dan polimorfisme sebagai komponen terpenting dari OOP.

Inti dari OOP

Kombinasi perpesanan dan enkapsulasi memiliki beberapa tujuan penting:

• Menghindari keadaan yang dapat diubah bersama dari suatu objek dengan mengenkapsulasi keadaan dan mengisolasi objek lain dari perubahan lokal di negaranya. Satu-satunya cara untuk mempengaruhi keadaan objek lain adalah memintanya (alih-alih memberinya perintah) untuk berubah dengan mengiriminya pesan. Perubahan status dipantau di tingkat lokal, seluler, status tidak tersedia untuk objek lain.
• Pemisahan objek dari satu sama lain. Pengirim pesan secara longgar digabungkan ke penerima melalui API perpesanan.
• Adaptasi dan resistensi terhadap perubahan selama pelaksanaan program melalui ikatan yang terlambat. Beradaptasi dengan perubahan selama eksekusi program menawarkan banyak keuntungan signifikan, yang menurut Alan Kay sangat penting bagi OOP.

Sumber inspirasi untuk Alan Kay, yang mengungkapkan ide-ide ini, adalah pengetahuannya tentang biologi, dan apa yang ia ketahui tentang ARPANET (ini adalah versi awal dari Internet). Yaitu, kita berbicara tentang sel biologis dan tentang komputer individu yang terhubung ke jaringan. Bahkan kemudian, Alan Kay membayangkan bagaimana program berjalan pada komputer besar yang terdistribusi (Internet), sementara komputer individu bertindak sebagai sel biologis, bekerja secara independen dengan keadaan terisolasi mereka sendiri dan bertukar data dengan komputer lain dengan mengirim pesan.

"Saya menyadari bahwa metafora untuk sebuah sel atau komputer akan membantu menyingkirkan data [...]." Alan Kay

Mengatakan "tolong singkirkan data", Alan Kay, tentu saja, sadar akan masalah yang disebabkan oleh keadaan yang bisa berubah bersama, dan konektivitas yang kuat yang disebabkan oleh berbagi data. Hari ini, topik ini banyak didengar. Tetapi pada akhir 1960-an, programmer ARPANET tidak senang dengan kebutuhan untuk memilih representasi model data untuk program mereka sebelum mengembangkan program. Pengembang ingin melepaskan diri dari praktik ini, karena, sebelumnya mengarahkan diri mereka ke dalam kerangka kerja yang ditentukan oleh penyajian data, lebih sulit untuk mengubah sesuatu di masa depan.

Masalahnya adalah berbagai cara penyajian data yang diperlukan, untuk akses ke mereka, kode yang berbeda dan sintaks yang berbeda dalam bahasa pemrograman yang digunakan di beberapa titik waktu. Holy Grail di sini akan menjadi cara universal untuk mengakses dan mengelola data. Jika semua data akan terlihat sama untuk program, ini akan menyelesaikan banyak masalah pengembang mengenai pengembangan dan pemeliharaan program.
Alan Kay mencoba "menyingkirkan" gagasan itu, yang menurutnya data dan program adalah, dalam arti tertentu, entitas independen. Mereka tidak dianggap seperti itu dalam Daftar atau dalam Smalltalk. Tidak ada pemisahan antara apa yang dapat dilakukan dengan data (dengan nilai, variabel, struktur data, dan sebagainya) dan konstruksi perangkat lunak seperti fungsi. Fungsinya adalah "warga negara kelas satu," dan program diizinkan untuk berubah selama eksekusi mereka. Dengan kata lain, Smalltalk tidak memiliki hubungan istimewa dan istimewa dengan data.

Alan Kay, apalagi, menganggap objek sebagai struktur aljabar, yang memberikan jaminan pasti, secara matematis terbukti dari perilaku mereka.

"Latar belakang matematis saya memungkinkan saya untuk memahami bahwa setiap objek dapat memiliki beberapa model aljabar yang terkait dengannya, bahwa mungkin ada seluruh kelompok model yang serupa, dan bahwa mereka bisa sangat, sangat berguna." Alan Kay

Terbukti memang demikian, dan ini menjadi dasar bagi objek, seperti janji dan lensa, apalagi, teori kategori dipengaruhi oleh keduanya.
Sifat aljabar bagaimana Alan Kay melihat objek akan memungkinkan objek memberikan verifikasi formal, perilaku deterministik, dan meningkatkan kemampuan uji, karena model aljabar, pada dasarnya, operasi yang mematuhi beberapa aturan dalam bentuk persamaan.

Dalam jargon programmer, "model aljabar" adalah abstraksi yang dibuat dari fungsi (operasi) yang disertai dengan aturan tertentu, ditegakkan oleh unit test yang harus dilewati oleh fungsi-fungsi ini (aksioma, persamaan).

Ide-ide ini telah dilupakan selama beberapa dekade di sebagian besar bahasa berorientasi objek dari keluarga C, termasuk C ++, Java, C #, dan sebagainya. Tetapi ide-ide ini memulai pencarian untuk perjalanan pulang, dalam versi terbaru dari bahasa berorientasi objek yang paling banyak digunakan.

Pada kesempatan ini, seseorang dapat mengatakan bahwa dunia pemrograman menemukan kembali manfaat pemrograman fungsional, dan memberikan argumen rasional dalam konteks bahasa berorientasi objek.

Seperti JavaScript dan Smalltalk sebelumnya, sebagian besar bahasa berorientasi objek modern menjadi lebih dan lebih "multi-paradigma". Tidak ada alasan untuk memilih antara pemrograman fungsional dan OOP. Ketika kita melihat esensi historis dari masing-masing pendekatan ini, mereka terlihat tidak hanya sebagai kompatibel, tetapi juga sebagai ide yang saling melengkapi.

Apa, sesuai dengan pemikiran Alan Kay, yang paling penting dalam PLO?

• Enkapsulasi.
• Olahpesan
• Pengikatan dinamis (kemampuan program untuk mengembangkan dan beradaptasi dengan perubahan selama pelaksanaannya).

Apa yang bisa diabaikan dalam OOP?

• Kelas.
• Warisan berbasis kelas.
• Hubungan khusus dengan objek, fungsi atau data.
• Kata kunci new .
• Polimorfisme.
• Pengetikan statis.
• Sikap terhadap kelas sebagai "tipe".

Jika Anda mengenal Java atau C #, Anda mungkin berpikir bahwa pengetikan statis atau polimorfisme adalah unsur terpenting OOP, tetapi Alan Kay lebih suka berurusan dengan pola perilaku universal dalam bentuk aljabar. Berikut adalah contoh yang ditulis dalam Haskell:

 fmap :: (a -> b) -> fa -> fb 

Ini adalah tanda tangan dari functor map universal, yang bekerja dengan tipe a dan b tidak terdefinisi, menerapkan fungsi dari a ke b dalam konteks functor a untuk membuat functor b . "Functor" adalah kata dari jargon matematika, yang artinya direduksi menjadi "mendukung operasi tampilan". Jika Anda terbiasa dengan metode [].map() dalam JavaScript, maka Anda sudah tahu apa artinya ini.

Berikut adalah beberapa contoh JavaScript:

 // isEven = Number => Boolean const isEven = n => n % 2 === 0; const nums = [1, 2, 3, 4, 5, 6]; //  map   `a => b`    `a` ( `this`) //     `b` //    `a`   `Number`,   `b`  `Boolean` const results = nums.map(isEven); console.log(results); // [false, true, false, true, false, true] 

Metode .map() bersifat universal, dalam arti bahwa a dan b dapat dari jenis apa pun, dan metode ini mengatasi situasi yang sama tanpa masalah, karena array adalah struktur data yang menerapkan hukum aljabar dari functors. Tipe untuk .map() tidak masalah, karena metode ini tidak mencoba untuk bekerja dengan nilai yang terkait secara langsung. Sebagai gantinya, ia menggunakan fungsi yang mengharapkan dan mengembalikan nilai dari tipe yang sesuai yang benar dari sudut pandang aplikasi.

 // matches = a => Boolean //  `a`    ,   const matches = control => input => input === control; const strings = ['foo', 'bar', 'baz']; const results = strings.map(matches('bar')); console.log(results); // [false, true, false] 

Hubungan tipe universal bisa sulit untuk diekspresikan dengan benar dan sepenuhnya dalam bahasa seperti TypeScript, tetapi sangat mudah dilakukan dalam sistem tipe Hindley-Milner yang digunakan dalam Haskell, yang mendukung tipe yang lebih tinggi (tipe tipe).

Sebagian besar sistem tipe memberlakukan pembatasan yang terlalu kuat untuk memungkinkan kebebasan berekspresi ide-ide dinamis dan fungsional, seperti komposisi fungsi, komposisi objek bebas, ekspansi objek selama eksekusi program, penggunaan kombinator, lensa, dan sebagainya. Dengan kata lain? tipe statis sering membuatnya sulit untuk menulis perangkat lunak menggunakan metode build.

Jika sistem tipe Anda memiliki terlalu banyak batasan (seperti dalam TypeScript atau Java), maka, untuk mencapai tujuan yang sama, Anda harus menulis kode yang lebih kompleks daripada saat menggunakan bahasa dengan pendekatan yang lebih bebas untuk mengetik. Ini tidak berarti bahwa menggunakan tipe statis adalah ide yang tidak menguntungkan, atau bahwa semua implementasi tipe statis memiliki batasan yang sama. Sebagai contoh, saya mengalami lebih sedikit masalah dalam bekerja dengan sistem tipe Haskell.

Jika Anda adalah penggemar tipe statis dan tidak menentang pembatasan, saya berharap Anda tujuh kaki di bawah lunas. Tetapi jika Anda menemukan bahwa beberapa ide yang diungkapkan di sini sulit untuk diterapkan karena fakta bahwa tidak mudah untuk mengetik fungsi yang diperoleh dengan menyusun fungsi lain dan struktur aljabar komposit, maka salahkan sistem tipe dan bukan idenya. Pengemudi menyukai fasilitas yang diberikan bingkai-SUV, tetapi tidak ada yang mengeluh bahwa mereka tidak bisa terbang. Untuk terbang, Anda membutuhkan kendaraan yang memiliki derajat kebebasan lebih tinggi.

Jika batasan membuat kode Anda lebih sederhana - hebat! Tetapi jika kendala memaksa Anda untuk menulis kode yang lebih kompleks, maka mungkin ada sesuatu yang salah dengan kendala ini.

Apa itu "objek"?

Kata "objek", dari waktu ke waktu, telah memperoleh banyak konotasi makna sekunder. Apa yang kita sebut "objek" dalam JavaScript hanyalah tipe data komposit, tanpa sedikit pun petunjuk tentang pemrograman berbasis kelas, atau ide penyampaian pesan Alan Kay.

Dalam JavaScript, objek-objek ini dapat mendukung, dan seringkali mendukung, enkapsulasi, menyampaikan pesan, pemisahan perilaku melalui metode, bahkan polimorfisme menggunakan subclass (meskipun menggunakan rantai delegasi daripada pengiriman berbasis tipe).

Alan Kay ingin menyingkirkan perbedaan antara program dan datanya. JavaScript, sampai batas tertentu, mencapai tujuan ini dengan menempatkan metode objek di tempat yang sama dengan properti yang menyimpan data. Properti apa pun, misalnya, dapat diberi fungsi apa pun. Anda dapat membangun perilaku objek secara dinamis dan mengubah konten semantik objek selama eksekusi program.

Objek hanya struktur data komposit, dan tidak perlu sesuatu yang istimewa untuk dianggap objek. Namun, pemrograman menggunakan objek tidak mengarah pada fakta bahwa kode tersebut ternyata "berorientasi objek", seperti halnya menggunakan fungsi tidak membuat kode "fungsional".

OOP bukan lagi OOP nyata

Karena konsep "objek" dalam bahasa pemrograman modern memiliki makna jauh lebih sedikit daripada yang dimaksudkan oleh Alan Kay, saya menggunakan kata "komponen" alih-alih kata "objek" untuk menggambarkan aturan OOP ini. Banyak objek yang secara langsung dimiliki dan dikendalikan oleh beberapa kode JavaScript pihak ketiga, tetapi komponen harus merangkum keadaan mereka sendiri dan mengendalikannya.

Inilah OOP yang sebenarnya:

• Pemrograman menggunakan komponen (Alan Kay menyebutnya "objek").
• Keadaan komponen harus dienkapsulasi.
• Untuk komunikasi antar entitas, olahpesan digunakan.
• Komponen dapat ditambahkan, dimodifikasi, dan diganti pada saat runtime.

Sebagian besar perilaku objek dapat didefinisikan secara universal menggunakan struktur data aljabar. Tidak perlu warisan. Komponen dapat menggunakan kembali perilaku dari fungsi publik dan mengimpor modul, tanpa harus mempublikasikan datanya.

Memanipulasi objek dalam JavaScript atau menggunakan warisan berbasis kelas tidak berarti seseorang terlibat dalam pemrograman OOP. Tetapi penggunaan komponen dengan cara seperti itu - berarti. Tetapi sangat sulit untuk menyingkirkan ide-ide mapan tentang istilah, jadi mungkin kita harus meninggalkan istilah "OOP" dan memanggil apa "komponen" di atas digunakan sebagai "Pemrograman Berorientasi Pesan (MOP)"? Kami akan menggunakan istilah "MOP" di bawah ini untuk berbicara tentang pemrograman berorientasi pesan.

Secara kebetulan, kata bahasa Inggris "pel" diterjemahkan sebagai "pel", dan, seperti yang Anda tahu, mereka digunakan untuk memulihkan ketertiban.

Seperti apa bentuk pel yang baik?

Sebagian besar program modern memiliki antarmuka pengguna (User Interface, UI) yang bertanggung jawab untuk berinteraksi dengan pengguna, beberapa kode yang mengelola keadaan aplikasi (data pengguna), dan kode yang berfungsi dengan sistem atau bertanggung jawab untuk bertukar data dengan jaringan.

Untuk mendukung operasi masing-masing sistem ini, proses yang berumur panjang, seperti pendengar acara, mungkin diperlukan. Di sini Anda akan memerlukan keadaan aplikasi - untuk menyimpan sesuatu seperti informasi tentang koneksi jaringan, tentang keadaan hubungan dengan kontrol antarmuka dan tentang aplikasi itu sendiri.

MOP yang baik berarti bahwa, alih-alih semua sistem tersebut memiliki akses ke status satu sama lain dan dapat mengontrolnya secara langsung, mereka berinteraksi satu sama lain melalui pesan. Ketika pengguna mengklik tombol "Simpan", pesan "SAVE" dapat dikirim. Komponen aplikasi manajemen negara dapat menafsirkan pesan ini dan mengarahkannya ke pawang yang bertanggung jawab untuk memperbarui dari negara (seperti fungsi reducer murni). Mungkin setelah memperbarui negara, komponen yang bertanggung jawab untuk mengelola negara mengirimkan pesan "STATE_UPDATED" komponen antarmuka pengguna, yang, pada gilirannya, menginterpretasikan keadaan, memutuskan bagian antarmuka mana yang perlu diperbarui, dan meneruskan negara yang diperbarui ke subkomponen yang bertanggung jawab untuk bekerja dengan elemen antarmuka spesifik.

Sementara itu, komponen yang bertanggung jawab untuk koneksi jaringan dapat memonitor koneksi pengguna ke komputer lain di jaringan, mendengarkan pesan, dan mengirim tampilan keadaan yang diperbarui untuk menyimpannya di mesin jarak jauh. Komponen seperti itu bertanggung jawab untuk bekerja dengan mekanisme jaringan, mengetahui apakah koneksi berfungsi atau tidak, dan sebagainya.

Sistem aplikasi yang serupa seharusnya tidak mengetahui detail bagian-bagian lainnya. Mereka seharusnya hanya peduli untuk menyelesaikan masalah mereka sendiri. Komponen sistem dapat dibongkar dan dirakit sebagai konstruktor. Mereka menerapkan antarmuka standar, yang berarti bahwa mereka dapat berinteraksi satu sama lain. Selama persyaratan yang terkenal untuk antarmuka komponen terpenuhi, komponen tersebut dapat diganti oleh yang lain, dengan antarmuka yang sama, tetapi melakukan hal yang sama secara berbeda, atau melakukan, menerima pesan yang sama, sesuatu yang sama sekali berbeda. Anda dapat mengubah satu komponen ke komponen lain bahkan selama eksekusi program - ini tidak akan merusak pekerjaannya.

Komponen sistem perangkat lunak bahkan tidak harus berada di komputer yang sama. Sistem dapat didesentralisasi. Penyimpanan jaringan dapat menempatkan data dalam sistem penyimpanan data terdesentralisasi seperti IPFS , sebagai akibatnya, pengguna tidak tergantung pada kesehatan mesin tertentu, yang menjamin keamanan datanya. Dengan pendekatan ini, data disimpan dan dilindungi dari pengganggu.

PLO, sebagian, berada di bawah pengaruh ide-ide ARPANET, dan salah satu tujuan proyek ini adalah untuk menciptakan jaringan terdesentralisasi yang tahan terhadap serangan seperti serangan nuklir.

Sistem MOP yang baik dapat ditandai dengan tingkat stabilitas yang sama menggunakan komponen yang mendukung hot swapping saat aplikasi sedang berjalan. Ini akan dapat terus berfungsi jika pengguna bekerja dengan itu dari ponsel dan berada di luar jangkauan jaringan karena fakta bahwa ia telah memasuki terowongan. Jika badai mengganggu catu daya salah satu pusat data di mana servernya berada, itu juga akan terus berfungsi.

Sudah saatnya bagi dunia perangkat lunak untuk membebaskan diri dari percobaan warisan berbasis kelas yang gagal dan mengadopsi prinsip-prinsip matematika dan ilmiah yang berada di garis depan OOP.

Waktunya telah tiba bagi kita para pengembang untuk membuat program yang lebih fleksibel, stabil, dan indah menggunakan kombinasi harmonis antara MOP dan pemrograman fungsional.
Omong-omong, akronim "MOP" sudah digunakan, menggambarkan "Pemrograman Berorientasi Pemantauan", tetapi konsep ini, tidak seperti OOP, akan hilang dengan tenang.

Karena itu, jangan berkecil hati jika istilah "MOP" tidak terlihat seperti kata dari jargon programmer. Rapikan OOP Anda dengan prinsip-prinsip MOP di atas.