Encapsulation

"Hello, Amigo! I want to dedicate today's lecture to encapsulation . Mayroon ka nang pangkalahatang ideya kung ano ito."

Kaya ano ang mga pakinabang ng encapsulation? Marami, ngunit ituturo ko ang apat na, sa aking pananaw, ang pinakamahalaga:

1) Wastong panloob na estado.

Ang mga programa ay madalas na may ilang mga klase na nakikipag-ugnayan sa parehong bagay. Sa pamamagitan ng sabay-sabay na pakikipag-ugnayan sa panloob na data ng object, maaari nilang labagin ang integridad ng data ng object, na magdulot ng bagay na huminto sa paggana ng tama.

Kaya dapat subaybayan ng object ang anumang mga pagbabago sa panloob na data nito, o mas mabuti pa - ito dapat ang gagawa ng mga pagbabagong iyon.

Kung hindi namin nais na baguhin ng ibang klase ang ilang variable ng klase, idineklara namin itong private , na nangangahulugan na ang mga pamamaraan ng klase lamang ang makaka-access dito. Kung gusto naming maging read-only ang mga variable para sa iba pang mga klase, pagkatapos ay idaragdag namin ang pampublikong getter sa mga variable na ito.

Halimbawa, maaaring gusto naming malaman ng lahat kung gaano karaming elemento ang mayroon sa aming koleksyon, ngunit walang sinuman ang dapat na makapagpabago nito nang walang pahintulot namin. Sa kasong ito, nagdedeklara kami ng variable na private int count at isang method na public getCount() .

Ginagarantiyahan ng wastong encapsulation na hindi direktang ma-access ng ibang mga klase ang panloob na data ng aming klase at, dahil dito, hindi ito mababago nang hindi namin makontrol ang kanilang mga aksyon. Dapat silang tumawag ng mga pamamaraan sa klase na naglalaman ng mga variable na babaguhin.

Pinakamainam na ipagpalagay na palaging gagamitin ng ibang programmer ang iyong mga klase sa paraang pinakakombenyente para sa kanila, hindi sa paraang pinakaligtas para sa iyo (o sa iyong klase). Ito ay isang mapagkukunan ng mga bug, at isang paraan upang maiwasan ang mga ito.

2) Pagsusuri ng parameter.

Minsan kailangan mong suriin ang mga parameter na ipinasa sa mga pamamaraan ng iyong klase. Halimbawa, ipagpalagay na mayroon kaming isang klase na kumakatawan sa isang "tao" at maaari mong tukuyin ang petsa ng kapanganakan nito. Dapat nating i-verify na ang anumang data na ipinasa ay tumutugma sa lohika ng programa at lohika ng klase. Halimbawa, walang 13th month, walang February 30, atbp.

"Bakit may magsasabi ng petsa ng kapanganakan noong Pebrero 30?"

"Well, una sa lahat, ito ay maaaring resulta ng isang error sa pagpasok ng data."

Pangalawa, bago gumana ang isang programa tulad ng clockwork, maaari itong magkaroon ng maraming mga bug. Halimbawa, maaaring mangyari ang isang bagay na tulad nito.

Ang isang programmer ay nagsusulat ng code na tumutukoy kung sino ang may kaarawan kinabukasan. Sabihin nating ngayon ay Marso 3. Ang programa ay nagdaragdag ng 2 sa kasalukuyang petsa at hinahanap ang lahat ng ipinanganak noong Marso 5. Sa ngayon, napakahusay.

Ngunit pagdating ng Marso 30, walang mahahanap ang programa, dahil walang Marso 32. Ang mga programa ay hindi gaanong buggy kapag ang mga pamamaraan ay nagsasagawa ng pagsusuri ng parameter."

"Naaalala ko noong nag-aral kami ng ArrayList tiningnan ko ang code nito, at may mga pagsusuri sa get at set na mga pamamaraan upang matiyak na ang parameter ng index ay mas malaki kaysa o katumbas ng zero at mas mababa sa haba ng array. Ang code ay magtapon ng isang exception kung ang array ay walang elementong naaayon sa index.

"Oo, iyon ang klasikong pagsusuri ng input. "

3) Mas kaunting mga bug kapag nagpapalit ng code sa loob ng mga klase.

Ipagpalagay na nagsulat kami ng isang talagang kapaki-pakinabang na klase bilang bahagi ng isang malaking proyekto. Nagustuhan ito ng lahat kaya sinimulan ng ibang programmer na gamitin ito sa daan-daang lugar sa sarili nilang code.

Ang klase ay napatunayang kapaki-pakinabang kaya nagpasya kang pagbutihin ito. Ngunit kung aalisin mo ang alinman sa mga pamamaraan sa klase, ang code ng dose-dosenang iba pang programmer ay hindi na mag-compile. Kailangan nilang mabilis na muling isulat ang kanilang code. At kung mas maraming muling pagsusulat na nangyayari, mas maraming pagkakataon para sa mga bug. Kung palagi mong sinisira ang build, kapopootan ka.

Ngunit kung babaguhin namin ang mga pamamaraan na minarkahan bilang pribado, alam namin na ang mga pamamaraang ito ay hindi tinatawag ng code ng sinuman saanman. Maaari naming muling isulat ang mga ito, at baguhin ang bilang at uri ng mga parameter, at gagana pa rin ang dependent code. O hindi bababa sa ito ay mag-compile pa rin.

4) Tinutukoy namin kung paano makikipag-ugnayan ang ibang mga bagay sa aming bagay.

Maaari naming paghigpitan kung anong mga aksyon ang maaaring gawin sa aming bagay. Halimbawa, maaaring gusto naming gumawa lamang ng isang instance ng isang klase—kahit na ginawa ito sa ilang lugar nang sabay-sabay sa proyekto. At makakamit natin ito gamit ang encapsulation.

Hinahayaan kami ng Encapsulation na magpataw ng mga karagdagang paghihigpit na maaaring maging mga karagdagang benepisyo . Halimbawa, ang klase ng String ay ipinatupad bilang isang hindi nababagong bagay. Ang isang instance ng String class ay hindi maaaring baguhin sa pagitan ng paglikha nito at pagkasira nito. Ang lahat ng mga pamamaraan ng String class (alisin, substring, ...) ay nagbabalik ng bagong string at sa anumang paraan ay hindi binabago ang object kung saan sila tinatawag.

"Holy cow. Kaya ganyan."

"Nakakaintriga ang encapsulation."

"Sumasang-ayon ako."