"Hello, Amigo! Nais kong sabihin sa iyo ang tungkol sa isa pang benepisyo ng OOP. Kita mo, ang mga programa ay mas katulad ng mga hayop kaysa sa mga gusali. Hindi sila itinayo, sila ay lumaki. Ang ibig sabihin ng pag-unlad ay patuloy na mga pagbabago. Sa konstruksiyon, maaari mong magkaroon ng isang magandang plano at sundin ito sa isang T. Ngunit sa pagbuo ng software, hindi iyon ang kaso."

Kadalasan, hindi mo magagawa ang isang bagay sa paraang nilayon mo, at kailangan mong muling isagawa ang iyong programa nang husto. At mas madalas, nagbabago ang mga kinakailangan ng customer.

"Ngunit paano kung ang customer ay nagbigay ng talagang detalyadong detalye?"

"Tingnan kung ano ang mangyayari sa paglipas ng panahon. Kung magtagumpay ang isang produkto, gugustuhin ng customer na maglabas ng bagong bersyon, at pagkatapos ay isa pa, at isa pa. At, siyempre, kailangan mong gumawa ng ilang « maliliit na pagbabago » sa ang umiiral na produkto. Kaya ang software development ay isang mahabang serye ng mga pagbabago. Ang cadence lang ang naiiba. Maaaring ilabas ang isang bagong bersyon bawat linggo, isang beses sa isang buwan, o bawat anim na buwan."

"So ano ang masasabi natin sa lahat ng ito?"

"Ang panloob na istraktura ng produkto ay dapat mapanatili sa paraang magpapahintulot sa mga malalaking (at menor de edad) na pagbabago na magawa nang may pinakamababang muling paggawa."

"Paano mo gagawin iyon?"

"Napag-usapan na natin kung paano binubuo ang isang programa ng mga bagay na nakikipag-ugnayan sa isa't isa. Gumamit tayo ng makapal na mga tuldok para kumatawan sa lahat ng mga bagay ng ating programa sa pisara. Gumuhit tayo ng mga arrow mula sa bawat bagay (tuldok) patungo sa lahat ng mga bagay. (mga tuldok) kung saan ito nakikipag-ugnayan."

Ngayon pagsamahin natin ang mga bagay (tuldok) sa mga pangkat. Ang mga tuldok ay nabibilang sa parehong pangkat kung sila ay higit na konektado sa isa't isa kaysa sa iba pang mga tuldok. Kung ang karamihan sa mga arrow ng isang tuldok ay tumuturo sa mga tuldok sa pangkat nito, pagkatapos ay ipinangkat namin nang tama ang mga bagay. Ang mga tuldok sa loob ng parehong pangkat ay sinasabing mahigpit na pinagsama, habang ang mga tuldok sa iba't ibang grupo ay maluwag na pinagsama.

Ito ay tinatawag na « prinsipyo ng maluwag na pagkabit ».Ang isang programa ay nahahati sa ilang bahagi, kadalasang mga layer, na ang lohika ay mahigpit na nakatali sa kanilang panloob na istraktura at mahinang nakatali sa iba pang mga layer/bahagi. Ang pakikipag-ugnayan sa pagitan ng mga layer ay kadalasang napaka-compartmentalized. Ang isang layer ay maaaring tumawag sa isa pang layer gamit lamang ang isang maliit na subset ng mga klase nito.

"Ang parehong prinsipyo ng 'dibisyon ng paggawa', ngunit sa mas malaking sukat?"

"Talaga. Ito ay nagpapahintulot sa amin na muling ayusin ang isang departamento, gawin itong mas mahusay, at kumuha ng mas maraming tao, at kung hindi namin babaguhin ang mga interdepartmental na protocol, kung gayon ang lahat ng aming mga pagbabago ay magiging lokal. Walang sinuman ang kailangang sanayin muli. Kailangang i-rework ang buong sistema. Maaaring i-optimize ng bawat departamento ang internal affairs nito sa ganitong paraan kung ang mga mekanismo para sa interaksyon ng departamento ay napiling mabuti."

"Kung mapili sila ng maayos. At paano kung hindi sila mapili ng maayos?"

'Pagkatapos ay mabilis kang mauubusan ng « wiggle room » para sa paggawa ng mga pagbabago, at kailangan mong i-rework ang buong system. Nangyayari iyon paminsan-minsan. Hindi namin mahuhulaan ang hinaharap, ngunit maaari naming i-minimize ang bilang ng beses na kailangan naming muling isulat ang programa."

"Okay. I see the benefit of dividing the program like that, but how does OOP come into the picture?"

"Kapag pinili namin kung paano bubuoin ang mga departamento at kung paano sila makikipag-ugnayan, inilalapat namin ang ' prinsipyo ng abstraction '. Sa programming, ginagamit ang abstraction upang matukoy ang pinakamahusay na paraan upang hatiin ang programa at kung paano dapat makipag-ugnayan ang mga bahagi. Ang prinsipyong ito ay maaaring paulit-ulit din itong inilalapat sa mga bahagi ng bumubuo hanggang sa mahati natin ang programa sa mga indibidwal na klase."

"At itinatago ang panloob na istraktura ng mga bahaging ito, at mahigpit na nililimitahan kung paano sila nakikipag-ugnayan sa ibang mga bahagi - iyon ay encapsulation , tama ba?"

"Eksakto. Ang encapsulation at abstraction ay mga pundasyon ng OOP. Ang isang mahusay na programa ay dapat sumunod sa dalawang prinsipyong ito. Sa ibang pagkakataon, titingnan natin ang iba pang mga prinsipyo at mauunawaan ang kanilang mga pakinabang."

"Good stuff. Hindi ako makapaghintay!"