1. Sajarah perusahaan

Aku arep kanggo pitutur marang kowe crita sing nduduhake carane OOP mbantu perang karo kerumitan sistem gedhe. Iki perlu kanggo sampeyan ngerti tujuan OOP .

Biyen ana perusahaan cilik sing nyedhiyakake layanan pengiriman antargalaksi...

Ayo diarani Galaxy Rush. Iku makaryakke 5 wong. Sing siji kerja ing keuangan, sing nomer loro kerja ing gudang, sing katelu ngirim, sing nomer papat ngurusi pariwara, lan sing kaping lima ngurusi kabeh perusahaan.

Padha buruh banget hard lan sukses ing kabeh. Perusahaan kasebut nduweni reputasi apik lan entuk dhuwit akeh. Nanging saben taun pesenan saya tambah akeh, mula bos kudu nyewa karyawan tambahan. Sawetara liyane kanggo gudang, sawetara liyane kanggo pangiriman, siji liyane kanggo keuangan, lan pakar iklan tambahan kanggo nggedhekake pangsa pasar perusahaan.

Lan nalika iku masalah diwiwiti. Ana liyane wong , lan padha wiwit njaluk ing cara saben liyane .

Pemasar mbuwang saluran akun bank ing kampanye iklan anyar, supaya ora ana dhuwit kanggo tuku produk sing kudu dikirim kanthi cepet.

Gudang kasebut duwe 10 drive hiper anyar sing dikirim menyang klien sapisan sasi. Siji kurir mabur lan njupuk drive hiper kanggo klien sing beda, nyebabake pesenan reguler kanggo 10 hyper drive ditundha sewulan. Kurir pisanan mung ora ngerti babagan pesenan liyane sing diisi dening kurir kaloro.

Asisten manajer anyar ngirim kurir menyang pesawat ruang angkasa kanggo tuku barang liyane. Sauntara kuwi, wong liya ngenteni kapal angkasa sing kasedhiya katon. Ana akeh kiriman sing penting, nanging asisten iki mung ngawasi pengadaan lan nyoba nindakake pakaryan kanthi apik. Sing luwih apik pegawe nindakake tugas, luwih ngganggu karya wong liya.

Java webinar

Nganalisa kahanan kasebut, bos ngerti manawa sumber daya penting kaya kapal angkasa, awis lan produk ora digunakake kanthi optimal. Nanging, dheweke tundhuk karo aturan "sampeyan tundha, sampeyan kalah". Sembarang karyawan bisa njupuk sumber daya sing dibutuhake wong liya kanggo pakaryane, saengga bisa mbebayani karyawan liyane lan perusahaan kanthi wutuh.

Ana sing kudu ditindakake, mula bos mutusake kanggo dibagi perusahaan monolitik dadi sawetara departemen. Dheweke nggawe departemen pengiriman, departemen pemasaran, departemen pengadaan, departemen keuangan, lan departemen inventarisasi. Ora ana sing bisa njupuk pesawat ruang angkasa maneh. Kepala departemen pengiriman nampa kabeh informasi babagan pangiriman lan ngetokake kapal menyang kurir kanthi urutan paling nguntungake. Kajaba iku, gudang kasebut ora ngidini kurir njupuk barang sing dikarepake. Nanging, njupuk produk saka gudang dadi proses sing dikontrol. Departemen keuangan ora bakal ngetokake dana kanggo kampanye pemasaran yen ngerti yen bakal ana tuku. Saben departemen duwe pasuryan umum - kepala departemen.Struktur internal saben departemen ana bisnis dhewe. Yen kurir pengin njaluk produk, dheweke menyang manajer gudang, dudu menyang gudang. Yen pesenan anyar teka, ditampa dening kepala departemen pengiriman ( public-facing representative) lan ora dening kurir ( someone not authorized to interact with the other departments).

Ing tembung liyane, bos nggabungake sumber daya lan tumindak sing nglibatake sumber daya menyang kelompok (departemen) , lan uga nglarang wong liya ngganggu struktur internal departemen. Interaksi antar departemen kudu liwat wong tartamtu.

Saka sudut pandang OOP , iki ora liya mung mbagi program dadi obyek. Program monolitik saka metode lan variabel dadi program sing kasusun saka obyek. Lan obyek duwe variabel lan metode.

Masalahe yaiku manawa karyawan bisa nggarap sumber daya apa wae lan menehi prentah marang karyawan liyane, kabeh tanpa pengawasan utawa kontrol. We dileksanakake watesan cilik, nanging ngrambah liyane supaya. Lan kita uga bisa ngontrol kabeh sing luwih apik.

Iki divide-and-conquer ing wangun paling murni.

2. Carane program digawe

Aku pengin ndemek siji titik sing luwih penting sing nuduhake keuntungan liyane saka OOP . Apa sampeyan ndeleng manawa program luwih kaya kewan tinimbang bangunan? Padha ora dibangun. Lagi thukul. Pembangunan minangka owah-owahan sing tetep. Ing construction, sampeyan bisa duwe rencana apik lan tindakake kanthi tliti. Iki ora kedadeyan karo pangembangan piranti lunak.

Asring banget ing pemrograman, sampeyan ora bisa nindakake apa-apa kaya sing dikarepake lan kudu ngolah maneh. Syarat pelanggan ganti luwih asring.

Nanging kepiye yen pelanggan menehi spesifikasi sing tepat banget? Sing nggawe kahanan luwih elek. Delengen apa sing kedadeyan karo produk sajrone wektu.

Kasuksesan produk bakal mimpin pelanggan pengin ngeculake versi anyar, banjur liyane lan liyane. Lan, mesthi, sampeyan mung kudu nambah "owahan cilik" menyang produk sing wis ana. Supaya sampeyan bisa ndeleng pangembangan produk minangka urutan owah-owahan konstan. Mung skala wektu sing beda. Versi anyar bisa dirilis seminggu sepisan, sasi sepisan utawa saben nem sasi.

Lan kesimpulan apa sing bisa dijupuk saka kabeh iki? Struktur internal produk kudu dijaga kanthi cara sing ngidini owah-owahan sing signifikan (lan suntingan) bisa ditindakake kanthi rework minimal.

Kohesi obyek

Nanging nindakake iku luwih angel tinimbang mutusake kanggo nindakake. Kita wis ujar manawa program kalebu obyek sing sesambungan karo siji liyane. Ayo digambar kabeh obyek program ing papan, makili kanthi poin. Lan ayo kang tarik panah saka saben obyek (titik) kanggo kabeh obyek liyane (titik) sing sesambungan karo.

Saiki kita bakal gabungke obyek (titik) menyang klompok. Poin kudu diklompokake yen sambungan ing antarane luwih kuat tinimbang karo titik liyane. Yen umume panah saka titik menyang titik liyane ing klompok dhewe, klompok kasebut dibentuk kanthi bener. Kita ngomong yen titik-titik ing sawijining klompok nduweni kohesi dhuwur , dene titik-titik ing klompok sing beda nduweni kohesi sing luwih murah.

Prinsip loose-coupling

Ana "prinsip kopling longgar". A program dipérang dadi sawetara bagéan, kang asring lapisan. Logika lapisan/bagean kasebut digandhengake kanthi rapet karo struktur internal lan longgar banget karo lapisan / bagean liyane. Interaksi antarane lapisan biasane diatur banget. Siji lapisan bisa uga ngrujuk menyang lapisan kapindho lan mung nggunakake subset cilik saka kelas kasebut. Iki minangka prinsip "mbagi perusahaan dadi departemen" sing kita deleng sadurunge, nanging kanthi skala sing luwih gedhe.

Asil kasebut yaiku kita bisa ngatur maneh departemen sing dibutuhake kanggo nambah efektifitas lan bisa nyewa luwih akeh wong kanggo departemen kasebut, lan anggere kita ora ngganti protokol interaksi karo departemen liyane, mula kabeh owah-owahan sing ditindakake bakal ditindakake. tetep lokal. Ora ana sing kudu sinau maneh. Sampeyan ora kudu rework kabeh sistem. Saben departemen bisa nindakake optimasi internal kaya iki yen mekanisme interaksi antar departemen dipilih kanthi apik.

Dipilih apik. Nanging kepiye yen dheweke ora dipilih kanthi apik? Banjur kapasitas kanggo owah-owahan cepet entek lan sampeyan kudu mbaleni kabeh sistem. Iki kudu ditindakake saka wektu kanggo wektu. Sampeyan ora bisa prédhiksi mangsa, nanging sampeyan bisa nyimpen jumlah redos kanggo minimal.

Prinsip abstraksi

Milih carane departemen disusun lan cara interaksi kasebut minangka " prinsip abstraksi ". Ing pemrograman, iki digunakake kanggo nemtokake cara sing paling apik kanggo ngilangi program dadi bagean-bagean konstituen lan carane bagean kasebut kudu sesambungan. Kita bisa ngetrapake prinsip kasebut, mbagi bagean-bagean sing diasilake dadi bagean, nganti kita wis ngilangi program kasebut dadi kelas individu.

Ndhelikake struktur internal bagean kasebut lan mbatesi interaksi karo bagean liyane yaiku enkapsulasi . Enkapsulasi lan abstraksi minangka landasan saka OOP . Program sing apik kudu ngetutake rong prinsip kasebut. Ing mangsa ngarep, kita bakal nliti prinsip liyane lan njelajah apa keuntungan sing diwenehake.