8.1 Dekomposisi iku kabeh
Kanggo gamblang, gambar saka artikel apik "Decoupling saka Object-Oriented Systems", nggambarake TCTerms utama sing bakal rembugan.
Apa sampeyan isih mikir yen ngrancang arsitektur aplikasi iku gampang?
8.2 Antarmuka, ndhelikake implementasine
Prinsip utama kanggo nyuda kopling sistem yaiku prinsip OOP lan prinsip Enkapsulasi + Abstraksi + Polimorfisme ing mburi.
Yo iku sebape:
- Modul kudu "kotak ireng" kanggo saben liyane (enkapsulasi) . Iki tegese siji modul ngirim ora "menek" menyang modul liyane lan ngerti apa-apa bab struktur internal sawijining. Obyek ing siji subsistem ngirim ora langsung ngakses obyek ing subsistem liyane.
- Modul/subsistem kudu sesambungan karo siji liyane mung liwat antarmuka (yaiku, abstraksi sing ora gumantung ing rincian implementasine). Mulane, saben modul kudu duwe antarmuka utawa antarmuka sing wis ditemtokake kanggo sesambungan karo modul liyane.
Prinsip "kotak ireng" (enkapsulasi) ngidini kita nimbang struktur saben subsistem kanthi bebas saka subsistem liyane. Modul, yaiku "kothak ireng", bisa diganti kanthi bebas. Masalah bisa muncul mung ing persimpangan modul sing beda (utawa modul lan lingkungan).
Lan interaksi iki kudu diterangake ing wangun paling umum (abstrak), yaiku, ing wangun antarmuka. Ing kasus iki, kode bakal padha karo implementasine sing cocog karo kontrak antarmuka. Iki minangka kemampuan kanggo nggarap implementasi sing beda (modul utawa obyek) liwat antarmuka terpadu sing diarani polimorfisme.
Pramila Servlet minangka antarmuka : wadhah web ora ngerti apa-apa babagan servlet, amarga iki sawetara obyek sing ngetrapake antarmuka Servlet lan mung. Servlets uga ngerti sethithik babagan struktur wadhah kasebut. Antarmuka Servlet yaiku kontrak kasebut, standar kasebut, interaksi minimal sing dibutuhake kanggo nggawe aplikasi web Java ngrebut jagad iki.
Polymorphism ora kabeh overriding saka cara, minangka kadhangkala salah pracaya, nanging pisanan kabeh, interchangeability saka modul / obyek karo antarmuka sing padha utawa "siji antarmuka, akeh implementasine". Kanggo ngleksanakake polimorfisme, mekanisme warisan ora dibutuhake. Iki penting dimangerteni amarga warisan umume kudu dihindari yen bisa .
Thanks kanggo antarmuka lan polymorphism, iku sabenere kemampuan kanggo ngowahi lan ngluwihi kode tanpa ngganti apa wis ditulis (Open-Closed Principle) wis ngrambah.
Anggere interaksi modul diterangake sacara eksklusif ing wangun antarmuka lan ora disambungake karo implementasine tartamtu, sampeyan duwe kesempatan kanggo pancen "ora lara" kanggo sistem ngganti siji modul karo liyane sing ngleksanakake antarmuka sing padha, uga. nambah sing anyar lan kanthi mangkono nggedhekake fungsi.
Iku kaya ing konstruktor LEGO - antarmuka standarisasi interaksi lan serves minangka jenis konektor ngendi wae modul karo konektor cocok bisa disambungake.
Keluwesan desainer dijangkepi kanthi kasunyatan manawa kita mung bisa ngganti siji modul utawa bagean liyane kanthi konektor sing padha (kanthi antarmuka sing padha), uga nambah bagean anyar sing dikarepake (ing wektu sing padha, ana. bagean ora diganti utawa diowahi kanthi cara apa wae).
Antarmuka ngidini sampeyan mbangun sistem sing luwih prasaja, nganggep saben subsistem kanthi sakabehe lan ora nggatekake struktur internal. Padha ngidini modul kanggo sesambungan lan ing wektu sing padha ora ngerti apa-apa bab struktur internal saben liyane, saéngga kanthi ngleksanakake prinsip kawruh minimal, kang basis saka kopling ngeculke.
Antarmuka sing luwih umum / abstrak ditetepake lan kurang watesan sing ditindakake ing interaksi, sistem luwih fleksibel. Saka kene, siji liyane saka prinsip SOLID bener nderek - Interface Segregation Principle , sing nentang "antarmuka tebal".
Dheweke ujar manawa antarmuka gedhe lan gedhe kudu dipérang dadi luwih cilik, luwih spesifik, supaya klien antarmuka cilik (modul gumantung) mung ngerti babagan cara sing kudu digarap.
Prinsip iki dirumusake kaya ing ngisor iki: "Klien ngirim ora gumantung ing metode (sing ngerti metode) sing ora digunakake" utawa "Akeh antarmuka khusus luwih apik tinimbang siji universal".
Pranyata panyambungan sing ringkih diwenehake mung nalika interaksi lan dependensi modul diterangake mung kanthi bantuan antarmuka, yaiku, abstraksi, tanpa nggunakake kawruh babagan struktur lan struktur internal, lan nyatane, enkapsulasi ditindakake. Kajaba iku, kita duwe kemampuan kanggo nggedhekake / ngganti prilaku sistem kanthi nambah lan nggunakake implementasine beda, yaiku, amarga polimorfisme. Ya, kita teka maneh menyang OOP - Enkapsulasi, Abstraksi, Polimorfisme.
8.3 Fasad: antarmuka modul
Ing kene, programmer sing berpengalaman bakal takon: yen desain ora ana ing tingkat obyek sing ngetrapake antarmuka sing cocog, nanging ing tingkat modul, mula apa implementasi antarmuka modul kasebut?
Jawaban: ngandika ing basa pola desain, banjur obyek khusus bisa tanggung jawab kanggo implementasine saka antarmuka modul - Facade . Yen sampeyan nelpon metode ing obyek sing ngemot suffix Gateway (contone, MobileApiGateway), banjur kemungkinan fasad.
Fasad minangka obyek antarmuka sing nglumpukake sakumpulan operasi tingkat dhuwur kanggo nggarap subsistem tartamtu, ndhelikake struktur internal lan kerumitan sing sejatine . Menehi pangayoman marang owah-owahan ing implementasine subsistem. Serves minangka titik entri siji - "sampeyan kick fasad, lan ngerti sing kudu kicked ing subsistem iki kanggo njaluk apa kang perlu."
Sampeyan mung wis dikenalaké kanggo salah siji saka pola desain paling penting sing ngijini sampeyan kanggo nggunakake konsep antarmuka nalika ngrancang modul lan kanthi mangkono decouple wong - "Facade".
Kajaba iku, "Facade" ndadekake iku bisa kanggo nggarap modul ing cara sing padha karo obyek biasa lan aplikasi kabeh prinsip migunani lan Techniques sing digunakake ing desain kelas nalika ngrancang modul.
Cathetan : Sanajan umume programer ngerti pentinge antarmuka nalika ngrancang kelas (obyek), misale jek akeh sing nemokake ide nggunakake antarmuka ing tingkat modul uga.