Mengapa kita memerlukan OOP?

1. Sejarah syarikat

Saya ingin memberitahu anda satu kisah yang menunjukkan cara OOP membantu melawan kerumitan sistem yang besar. Ini adalah perlu untuk anda memahami tujuan OOP .

Pada suatu masa dahulu terdapat sebuah syarikat kecil yang menyediakan perkhidmatan perkapalan antara galaksi...

Mari kita panggil ia Galaxy Rush. Ia menggaji 5 orang. Seorang bekerja dalam bidang kewangan, yang kedua bekerja di gudang, yang ketiga melakukan penghantaran, yang keempat mengendalikan pengiklanan, dan yang kelima menguruskan keseluruhan perusahaan.

Mereka adalah pekerja yang sangat gigih dan berjaya dalam segala-galanya. Syarikat itu mempunyai reputasi yang baik dan memperoleh banyak wang. Tetapi setiap tahun semakin banyak pesanan, jadi bos terpaksa mengambil pekerja tambahan. Beberapa lagi untuk gudang, beberapa lagi untuk penghantaran, satu lagi untuk kewangan, dan pakar pengiklanan tambahan untuk mengembangkan bahagian pasaran syarikat.

Dan ketika itulah masalah bermula. Terdapat lebih ramai orang , dan mereka mula menghalang satu sama lain.

Pemasar membelanjakan mengalirkan akaun bank pada kempen pengiklanan baharu, jadi tiada wang untuk membeli produk yang perlu dihantar segera.

Gudang ini mempunyai 10 pemacu hiper baharu yang dihantar kepada pelanggan sekali sebulan. Satu kurier masuk dan mengambil pemacu hiper untuk pelanggan lain, menyebabkan pesanan biasa untuk 10 pemacu hiper tertunda selama sebulan. Kurier pertama langsung tidak tahu tentang pesanan lain yang diisi oleh kurier kedua itu.

Penolong pengurus baharu menghantar kurier pergi dengan kapal angkasa untuk membeli lebih banyak barangan. Sementara itu, orang lain menunggu kapal angkasa yang tersedia muncul. Terdapat banyak penghantaran segera, tetapi pembantu ini hanya mengawasi perolehan dan cuba menjalankan tugasnya dengan baik. Lebih baik pekerja menjalankan tugasnya, lebih banyak dia mengganggu kerja orang lain.

Menganalisis keadaan, bos menyedari bahawa sumber penting seperti kapal angkasa, wang tunai dan produk tidak digunakan secara optimum. Sebaliknya, mereka tertakluk kepada peraturan "anda tunda, anda kalah". Mana-mana pekerja boleh mengambil sumber yang diperlukan oleh semua orang untuk kerja mereka, dengan itu membahayakan pekerja lain dan syarikat secara keseluruhan.

Sesuatu perlu dilakukan, jadi bos memutuskan untuk membahagikan syarikat monolitik itu kepada beberapa jabatan. Dia mencipta jabatan perkapalan, jabatan pemasaran, jabatan perolehan, jabatan kewangan, dan jabatan inventori. Tiada lagi sesiapa yang boleh mengambil kapal angkasa itu. Ketua jabatan perkapalan menerima semua maklumat tentang penghantaran dan mengeluarkan kapal kepada kurier dengan pesanan yang paling menguntungkan. Selain itu, gudang tidak membenarkan kurier mengambil apa-apa barangan yang mereka mahukan. Sebaliknya, memilih produk dari gudang menjadi proses terkawal. Jabatan kewangan tidak akan mengeluarkan dana untuk kempen pemasaran jika ia tahu bahawa akan ada pembelian tidak lama lagi. Setiap jabatan mempunyai satu muka awam — ketua jabatan.Struktur dalaman setiap jabatan adalah perniagaannya sendiri. Jika kurier ingin mendapatkan produk, dia pergi ke pengurus gudang, bukan ke gudang. Jika pesanan baru masuk, ia diterima oleh ketua jabatan perkapalan ( public-facing representative) dan bukan oleh kurier ( someone not authorized to interact with the other departments).

Dalam erti kata lain, bos menyatukan sumber dan tindakan yang melibatkan sumber kepada kumpulan (jabatan) , dan juga melarang orang lain mengganggu struktur dalaman jabatan. Interaksi antara jabatan terpaksa melalui orang tertentu.

Dari sudut pandangan OOP , ini tidak lebih daripada membahagikan program kepada objek. Program monolitik kaedah dan pembolehubah menjadi program yang terdiri daripada objek. Dan objek mempunyai pembolehubah dan kaedah.

Masalahnya ialah mana-mana pekerja boleh bekerja dengan mana-mana sumber dan memberi arahan kepada mana-mana pekerja lain, semuanya tanpa pengawasan atau kawalan. Kami mengenakan sekatan kecil, tetapi mencapai lebih banyak perintah. Dan kami juga dapat mengawal segala-galanya dengan lebih baik.

Ini adalah divide-and-conquer dalam bentuk yang paling tulen.

2. Bagaimana program dicipta

Saya ingin menyentuh satu lagi perkara penting yang mendedahkan satu lagi kelebihan OOP . Adakah anda melihat bahawa program lebih seperti haiwan daripada bangunan? Mereka tidak dibina. Mereka sudah dewasa. Pembangunan adalah perubahan yang berterusan. Dalam pembinaan, anda boleh mempunyai rancangan yang baik dan mengikutinya dengan tepat. Ini tidak berlaku dengan pembangunan perisian.

Selalunya dalam pengaturcaraan, anda tidak boleh melakukan sesuatu seperti yang anda maksudkan pada asalnya dan mesti banyak mengolah semula. Keperluan pelanggan berubah lebih kerap.

Tetapi bagaimana jika pelanggan memberikan spesifikasi yang sangat tepat? Itu memburukkan lagi keadaan. Lihat apa yang berlaku dengan produk dari semasa ke semasa.

Kejayaan produk akan menyebabkan pelanggan ingin mengeluarkan versi baharu, dan kemudian satu lagi dan satu lagi. Dan, sudah tentu, anda hanya perlu menambah "perubahan kecil" pada produk sedia ada. Jadi anda boleh melihat pembangunan produk adalah urutan perubahan yang berterusan. Cuma skala masa sahaja yang berbeza. Versi baharu boleh dikeluarkan seminggu sekali, sebulan sekali atau enam bulan sekali.

Dan apakah kesimpulan yang boleh kita buat dari semua ini? Struktur dalaman produk perlu dikekalkan dengan cara yang membolehkan perubahan ketara (dan kecil) dibuat dengan kerja semula yang minimum.

Kesepaduan objek

Tetapi melakukan itu lebih sukar daripada memutuskan untuk melakukannya. Kami telah mengatakan bahawa program terdiri daripada objek yang berinteraksi antara satu sama lain. Mari kita lukis semua objek program kita di papan tulis, mewakilinya dengan mata. Dan mari kita lukis anak panah dari setiap objek (titik) ke semua objek lain (titik) yang berinteraksi dengannya.

Sekarang kita akan menggabungkan objek (mata) ke dalam kumpulan. Mata harus dikumpulkan jika hubungan antara mereka jauh lebih sengit daripada mata yang lain. Jika kebanyakan anak panah dari satu titik pergi ke titik lain dalam kumpulannya sendiri, maka kumpulan itu telah dibentuk dengan betul. Kami mengatakan bahawa mata dalam kumpulan mempunyai kohesi yang tinggi manakala mata dalam kumpulan berbeza mempunyai kohesi yang lebih rendah.

Prinsip gandingan longgar

Terdapat "prinsip gandingan longgar". Sesuatu program dibahagikan kepada beberapa bahagian, yang selalunya merupakan lapisan. Logik lapisan/bahagian ini digandingkan rapat dengan struktur dalamannya dan sangat longgar digandingkan dengan lapisan/bahagian lain. Interaksi antara lapisan biasanya sangat terkawal. Satu lapisan mungkin merujuk kepada lapisan kedua dan hanya menggunakan subset kecil kelasnya. Ini adalah prinsip "membahagikan syarikat kepada jabatan" yang kita lihat sebelum ini, tetapi pada skala yang lebih besar.

Hasilnya ialah kita boleh menyusun semula jabatan mengikut keperluan untuk meningkatkan keberkesanannya dan kita boleh mengambil lebih ramai orang untuk jabatan itu, dan selagi kita tidak mengubah protokol interaksi dengan jabatan kita yang lain, maka semua perubahan yang dibuat akan kekal tempatan. Tiada siapa yang perlu belajar semula apa-apa. Anda tidak perlu mengolah semula keseluruhan sistem. Setiap jabatan boleh melakukan pengoptimuman dalaman seperti ini jika mekanisme untuk interaksi antara jabatan dipilih dengan baik.

Dipilih dengan baik. Tetapi bagaimana jika mereka tidak dipilih dengan baik? Kemudian kapasiti untuk perubahan cepat habis dan anda perlu membuat semula keseluruhan sistem. Ini perlu dilakukan dari semasa ke semasa. Anda tidak boleh meramalkan masa depan, tetapi anda boleh mengekalkan bilangan ulangan kepada minimum.

Prinsip abstraksi

Memilih cara jabatan distrukturkan dan cara ia berinteraksi ialah " prinsip abstraksi ". Dalam pengaturcaraan, ia digunakan untuk menentukan cara terbaik untuk memecahkan program kepada bahagian konstituen dan bagaimana bahagian tersebut harus berinteraksi. Kita boleh menggunakan semula prinsip, membahagikan bahagian yang terhasil kepada bahagian, sehingga kita telah memecahkan atur cara ke dalam kelas individu.

Menyembunyikan struktur dalaman bahagian ini dan mengehadkan interaksi dengan bahagian lain secara ketat ialah enkapsulasi . Enkapsulasi dan pengabstrakan adalah asas kepada OOP . Program yang baik mesti mengikut dua prinsip ini. Pada masa hadapan, kami akan melihat selebihnya prinsip dan meneroka manfaat yang diberikannya.