4.1 Tagabuo
Ang Builder ay isang generative na pattern ng disenyo na nagbibigay ng paraan upang lumikha ng composite object.
Pinaghihiwalay ang pagbuo ng isang kumplikadong bagay mula sa representasyon nito upang ang parehong proseso ng pagtatayo ay maaaring magresulta sa iba't ibang mga representasyon.
Mga kalakasan:
- nagpapahintulot sa iyo na baguhin ang panloob na representasyon ng produkto;
- ihiwalay ang code na nagpapatupad ng konstruksiyon at pagtatanghal;
- nagbibigay ng mas pinong kontrol sa proseso ng disenyo.
Mga mahinang panig:
- ang algorithm para sa paglikha ng isang kumplikadong bagay ay hindi dapat nakasalalay sa kung anong mga bahagi ang binubuo ng bagay at kung paano sila magkasya;
- ang proseso ng pagtatayo ay dapat magbigay ng iba't ibang representasyon ng bagay na ginagawa.
Ang isang magandang halimbawa ay ang klase ng HttpRequest, na mayroong subclass na HttpRequest.Builder na maaaring magamit upang lumikha ng mga instance ng klase ng HttpRequest at matiyak na wasto ang mga ito.
4.2 Tamad na pagsisimula
Ang lazy initialization ay isang programming technique kapag ang ilang resource-intensive na operasyon (paggawa ng bagay, pagkalkula ng halaga) ay ginanap kaagad bago ang resulta nito.
Kaya, ang pagsisimula ay isinasagawa "on demand", at hindi nang maaga. Ang isang katulad na ideya ay nakakahanap ng aplikasyon sa iba't ibang lugar: halimbawa, on-the-fly compilation at ang Just-in-Time na konsepto ng logistik.
Ang isang espesyal na kaso ng tamad na pagsisimula - ang paglikha ng isang bagay sa oras ng pag-access dito - ay isa sa mga pattern ng pagbuo ng disenyo. Karaniwan itong ginagamit kasabay ng mga pattern tulad ng Factory Method, Loner, at Proxy.
Mga kalakasan:
- Ang pagsisimula ay isinasagawa lamang kapag ito ay talagang kinakailangan;
- Ang paunang pagsisimula ng aplikasyon ay pinabilis: lahat ng maaaring ipagpaliban ay ipinagpaliban.
Mga mahinang panig:
- Hindi posibleng tahasang itakda ang pagkakasunud-sunod kung saan sinisimulan ang mga bagay;
- Mayroong pagkaantala sa unang pag-access sa bagay, na maaaring maging kritikal kapag ang isa pang operasyong masinsinang mapagkukunan ay gumanap nang magkatulad. Dahil dito, kinakailangang maingat na isaalang-alang ang pagiging angkop ng paggamit ng tamad na pagsisimula sa multithreaded software system.
Tandaan kung paano kapag nagsusulat ng web.xml maaari mong tukuyin ang panimulang pagkakasunud-sunod ng mga servlet doon? Ito ay eksaktong resulta ng tamad na pag-load. Gagawa ang Tomcat ng mga servlet object sa unang pagkakataon na ma-access ang mga ito.
4.3 Object pool
Ang object pool ay isang pattern ng disenyo ng magulang, isang set ng mga nasimulan at handa nang gamitin na mga bagay. Kapag ang system ay nangangailangan ng isang bagay, hindi ito nilikha, ngunit kinuha mula sa pool. Kapag hindi na kailangan ang isang bagay, hindi ito nasisira ngunit ibinalik sa pool.
Ginagamit ang Object pooling upang pahusayin ang performance kapag gumagawa ng object sa simula ng trabaho at ang pagsira nito sa dulo ay mahal. Ang pagpapabuti ng pagganap ay lalo na kapansin-pansin kapag ang mga bagay ay nilikha at sinisira nang madalas, ngunit kakaunti lamang sa mga ito ang umiiral sa parehong oras.
Ang isang object pool ay kapaki-pakinabang kapag ang isang object ay nagmamay-ari ng mga mapagkukunan maliban sa memorya, tulad ng mga network socket. O kung ang koleksyon ng mga bagay ay tumatagal ng isang makabuluhang bahagi ng memorya ng computer at maraming "basura" ang nalikha.
Tulad ng naaalala mo, ang Tomcat ay nagpapatupad ng bawat kahilingan sa isang hiwalay na thread. Ngunit ang mga thread ay hindi ginagawa sa bawat pagkakataon, ngunit naka-imbak sa thread pool. Ito ay nagbibigay-daan sa mas mabilis na pagpapatupad ng mga kahilingan: kapag ang isang thread ay kinakailangan, ito ay kinuha lamang mula sa pool. Sa pamamagitan ng paraan, ang tanong ay: paano mo ilalagay ang tumatakbong thread sa pool at kunin ito mula sa pool?