Mengapa kita membutuhkan OOP?

1. Sejarah perusahaan

Saya ingin menceritakan sebuah kisah yang menunjukkan bagaimana OOP membantu melawan kompleksitas sistem besar. Ini diperlukan agar Anda memahami tujuan OOP .

Dahulu kala ada sebuah perusahaan kecil yang menyediakan jasa pengiriman antargalaksi...

Sebut saja Galaxy Rush. Ini mempekerjakan 5 orang. Satu bekerja di bidang keuangan, yang kedua bekerja di gudang, yang ketiga melakukan pengiriman, yang keempat menangani iklan, dan yang kelima mengelola seluruh perusahaan.

Mereka adalah pekerja yang sangat keras dan berhasil dalam segala hal. Perusahaan memiliki reputasi yang baik dan menghasilkan banyak uang. Tetapi setiap tahun pesanan semakin banyak, sehingga bos harus mempekerjakan karyawan tambahan. Beberapa lagi untuk gudang, beberapa lagi untuk pengiriman, satu lagi untuk keuangan, dan tambahan ahli periklanan untuk memperluas pangsa pasar perusahaan.

Dan saat itulah masalah dimulai. Ada lebih banyak orang , dan mereka mulai saling menghalangi.

Pemasar menghabiskan rekening bank untuk kampanye iklan baru, jadi tidak ada uang untuk membeli produk yang sangat perlu dikirim.

Gudang tersebut memiliki 10 hyper drive baru yang dikirim ke klien sebulan sekali. Seorang kurir terbang masuk dan mengambil hyper drive untuk klien yang berbeda, menyebabkan pesanan reguler untuk 10 hyper drive tertunda sebulan. Kurir pertama sama sekali tidak tahu tentang pesanan lain yang diisi oleh kurir kedua itu.

Asisten manajer baru mengirim seorang kurir dengan pesawat ruang angkasa untuk membeli lebih banyak barang. Sementara itu, semua orang menunggu pesawat luar angkasa yang tersedia muncul. Ada banyak pengiriman mendesak, tetapi asisten ini hanya mengawasi pengadaan dan berusaha melakukan pekerjaannya dengan baik. Semakin baik seorang karyawan melakukan tugasnya, semakin dia mengganggu pekerjaan orang lain.

Menganalisis situasi, bos menyadari bahwa sumber daya penting seperti pesawat luar angkasa, uang tunai, dan produk tidak digunakan secara optimal. Sebaliknya, mereka tunduk pada aturan "Anda tunda, Anda kalah". Setiap karyawan dapat mengambil sumber daya yang dibutuhkan orang lain untuk pekerjaan mereka, sehingga membahayakan karyawan lain dan perusahaan secara keseluruhan.

Sesuatu harus dilakukan, jadi bos memutuskan untuk membagi perusahaan monolitik menjadi beberapa departemen. Dia menciptakan departemen pengiriman, departemen pemasaran, departemen pengadaan, departemen keuangan, dan departemen inventaris. Tidak ada lagi yang bisa mengambil pesawat luar angkasa begitu saja. Kepala departemen pengiriman menerima semua informasi tentang pengiriman dan menyerahkan kapal kepada kurir dengan pesanan yang paling menguntungkan. Selain itu, gudang tidak mengizinkan kurir mengambil barang apa pun yang mereka inginkan. Sebaliknya, memilih produk dari gudang menjadi proses yang terkendali. Departemen keuangan tidak akan mengucurkan dana untuk kampanye pemasaran jika tahu akan ada pembelian dalam waktu dekat. Setiap departemen memiliki satu wajah publik - kepala departemen.Struktur internal setiap departemen adalah urusannya sendiri. Jika seorang kurir ingin mendapatkan produk, dia pergi ke pengelola gudang, bukan ke gudang. Jika pesanan baru masuk, diterima oleh kepala departemen pengiriman ( public-facing representative) dan bukan oleh kurir ( someone not authorized to interact with the other departments).

Dengan kata lain, bos mengkonsolidasikan sumber daya dan tindakan yang melibatkan sumber daya ke dalam kelompok (departemen) , dan juga melarang orang lain mengganggu struktur internal departemen. Interaksi antardepartemen harus melalui orang tertentu.

Dari sudut pandang OOP , ini tidak lebih dari membagi program menjadi objek. Program metode dan variabel monolitik menjadi program yang terdiri dari objek. Dan objek memiliki variabel dan metode.

Masalahnya adalah setiap karyawan dapat bekerja dengan sumber daya apa pun dan memberikan perintah kepada karyawan lain, semuanya tanpa pengawasan atau kontrol. Kami memberlakukan batasan kecil, tetapi mencapai lebih banyak ketertiban. Dan kami juga dapat mengontrol segalanya dengan lebih baik.

Ini adalah membagi-dan-menaklukkan dalam bentuknya yang paling murni.

2. Bagaimana program dibuat

Saya ingin menyinggung satu poin penting lagi yang mengungkapkan keuntungan lain dari OOP . Apakah Anda melihat bahwa program lebih seperti binatang daripada bangunan? Mereka tidak dibangun. Mereka tumbuh. Perkembangan adalah perubahan yang konstan. Dalam konstruksi, Anda dapat memiliki rencana yang baik dan mengikutinya dengan tepat. Ini tidak terjadi dengan pengembangan perangkat lunak.

Sangat sering dalam pemrograman, Anda tidak dapat melakukan sesuatu seperti yang Anda inginkan dan harus banyak mengerjakan ulang. Persyaratan pelanggan berubah lebih sering.

Namun bagaimana jika pelanggan memberikan spesifikasi yang sangat tepat? Itu membuat segalanya menjadi lebih buruk. Lihatlah apa yang terjadi dengan produk dari waktu ke waktu.

Kesuksesan produk akan membuat pelanggan ingin merilis versi baru, lalu versi lainnya dan lainnya. Dan, tentu saja, yang perlu Anda lakukan hanyalah menambahkan "perubahan kecil" pada produk yang sudah ada. Jadi Anda bisa melihat pengembangan produk adalah rangkaian perubahan konstan. Hanya skala waktunya saja yang berbeda. Versi baru dapat dirilis seminggu sekali, sebulan sekali, atau enam bulan sekali.

Dan kesimpulan apa yang bisa kita tarik dari semua ini? Struktur internal produk perlu dipertahankan dengan cara yang memungkinkan perubahan signifikan (dan kecil) dilakukan dengan pengerjaan ulang yang minimal.

kohesi objek

Tetapi melakukan itu lebih sulit daripada memutuskan untuk melakukannya. Kami telah mengatakan bahwa sebuah program terdiri dari objek yang berinteraksi satu sama lain. Mari menggambar semua objek program kita di papan tulis, mewakilinya dengan poin. Dan mari menggambar panah dari setiap objek (titik) ke semua objek (titik) lain yang berinteraksi dengannya.

Sekarang kita akan menggabungkan objek (poin) ke dalam grup. Poin harus dikelompokkan jika koneksi di antara mereka jauh lebih kuat daripada poin lainnya. Jika sebagian besar anak panah dari suatu titik menuju ke titik lain dalam kelompoknya sendiri, maka kelompok tersebut dibentuk dengan benar. Kami mengatakan bahwa titik-titik dalam suatu kelompok memiliki kohesi yang tinggi sedangkan titik-titik dalam kelompok yang berbeda memiliki kohesi yang lebih rendah.

Prinsip kopling longgar

Ada "prinsip kopling longgar". Suatu program dibagi menjadi beberapa bagian, yang seringkali merupakan lapisan. Logika lapisan/bagian ini terkait erat dengan struktur internalnya dan terkait sangat longgar dengan lapisan/bagian lainnya. Interaksi antar lapisan biasanya sangat teratur. Satu lapisan mungkin merujuk ke lapisan kedua dan hanya menggunakan sebagian kecil dari kelasnya. Ini adalah prinsip "membagi perusahaan menjadi beberapa departemen" yang kita lihat sebelumnya, tetapi dalam skala yang lebih besar.

Hasilnya adalah kami dapat mengatur ulang departemen sesuai kebutuhan untuk meningkatkan efektivitasnya dan kami dapat mempekerjakan lebih banyak orang untuk departemen tersebut, dan selama kami tidak mengubah protokol interaksi dengan departemen kami yang lain, maka semua perubahan yang dilakukan akan tetap lokal. Tidak ada yang harus mempelajari kembali apa pun. Anda tidak perlu mengerjakan ulang seluruh sistem. Setiap departemen dapat melakukan optimalisasi internal semacam ini jika mekanisme interaksi antar departemen dipilih dengan baik.

Dipilih dengan baik. Tetapi bagaimana jika mereka tidak dipilih dengan baik? Kemudian kapasitas untuk perubahan akan habis dengan cepat dan Anda harus mengulang seluruh sistem. Ini harus dilakukan dari waktu ke waktu. Anda tidak dapat memprediksi masa depan, tetapi Anda dapat meminimalkan jumlah pengulangan.

Prinsip abstraksi

Memilih bagaimana departemen disusun dan bagaimana mereka berinteraksi adalah " prinsip abstraksi ". Dalam pemrograman, ini digunakan untuk menentukan cara terbaik untuk memecah program menjadi bagian-bagian penyusunnya dan bagaimana bagian-bagian itu harus berinteraksi. Kita dapat menerapkan kembali prinsipnya, membagi bagian yang dihasilkan menjadi beberapa bagian, hingga kita memecah program menjadi kelas-kelas individual.

Menyembunyikan struktur internal bagian-bagian ini dan secara ketat membatasi interaksi dengan bagian lain adalah enkapsulasi . Enkapsulasi dan abstraksi adalah landasan dari OOP . Program yang baik harus mengikuti kedua prinsip ini. Di masa mendatang, kita akan melihat prinsip-prinsip lainnya dan mengeksplorasi manfaat apa yang mereka berikan.