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.
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.
Sadurunge wulangan sadurunge
Sabanjure wulangan sabanjuré
Komentar
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION
sinau
Registrasi
Kursus Jawa
Bantuan karo Tugas
pricing
Proyek Game
Sintaksis Jawa
Masyarakat
Pangguna
Artikel
Forum
Ngobrol
Kisah Sukses
Kegiatan
Program Afiliasi
Perusahaan
Babagan awake dhewe
Kontak
Ulasan
Ruang Pers
CodeGym kanggo EDU
FAQ
Nyokong
CodeGym minangka kursus online kanggo sinau pemrograman Java wiwit wiwitan. Kursus iki minangka cara sing sampurna kanggo nguasai Java kanggo pamula. Isine luwih saka 1200 tugas kanthi verifikasi cepet lan ruang lingkup teori dhasar Jawa. Kanggo mbantu sampeyan sukses ing pendhidhikan, kita wis ngetrapake sawetara fitur motivasi: kuis, proyek coding, konten babagan sinau sing efisien lan karir pangembang Jawa.
Tindakake kita
Basa antarmuka
Basa Jawa
Programmer Digawe, Ora Lair © 2023 CodeGym
Unduh App
Programmer Digawe, Ora Lair © 2023 CodeGym
Situs web iki nggunakake cookie kanggo nyedhiyakake layanan pribadi. Kanthi nggunakake situs web iki, sampeyan setuju kanggo nggunakake cookie. Yen sampeyan mbutuhake rincian liyane, waca Katentuan lan Kebijakan.