Bakit kailangan natin ng OOP?

1. Kasaysayan ng kumpanya

Gusto kong sabihin sa iyo ang isang kuwento na nagpapakita kung paano nakakatulong ang OOP na labanan ang pagiging kumplikado ng malalaking system. Ito ay kinakailangan para maunawaan mo ang layunin ng OOP .

Noong unang panahon mayroong isang maliit na kumpanya na nagbibigay ng mga serbisyo sa pagpapadala ng intergalactic...

Tawagan natin itong Galaxy Rush. Nagtrabaho ito ng 5 tao. Ang isa ay nagtrabaho sa pananalapi, ang pangalawa ay nagtrabaho sa isang bodega, ang ikatlo ay ang naghahatid, ang ikaapat ay humawak ng advertising, at ang ikalima ay namamahala sa buong negosyo.

Napakasipag nilang manggagawa at nagtagumpay sa lahat ng bagay. Ang kumpanya ay may magandang reputasyon at kumita ng maraming pera. Ngunit bawat taon ay dumami ang mga order, kaya ang boss ay kailangang kumuha ng karagdagang mga empleyado. Marami pa para sa bodega, marami pa para sa mga paghahatid, isa pa para sa pananalapi, at karagdagang eksperto sa advertising upang palawakin ang market share ng kumpanya.

At doon nagsimula ang mga problema. Mas dumami ang mga tao , at nagsimula silang humarang sa isa't isa.

Ang marketer ay gumagastos ng bank account sa isang bagong advertising campaign, kaya walang pera para bumili ng mga produkto na apurahang kailangang ipadala.

Ang bodega ay may 10 bagong-bagong hyper drive na naipapadala sa isang kliyente isang beses sa isang buwan. Lumipad ang isang courier at inalis ang isang hyper drive para sa ibang kliyente, na naging dahilan upang maantala ng isang buwan ang regular na order para sa 10 hyper drive. Hindi lang alam ng unang courier ang tungkol sa ibang order na pinupunan ng pangalawang courier.

Ang bagong assistant manager ay nagpapadala ng isang courier sa isang spaceship upang bumili ng higit pang mga produkto. Samantala, ang iba ay naghihintay para sa isang magagamit na spaceship na lumitaw. Maraming mga apurahang paghahatid, ngunit ang katulong na ito ay nangangasiwa lamang sa pagkuha at sinusubukang gawin ang kanyang trabaho nang maayos. Kung mas mahusay na ginagampanan ng isang empleyado ang kanyang mga tungkulin, mas nakikialam siya sa gawain ng iba.

Sa pagsusuri sa sitwasyon, napagtanto ng boss na ang mahahalagang mapagkukunan tulad ng spaceship, cash at mga produkto ay hindi ginagamit nang mahusay. Sa halip, napapailalim sila sa panuntunang "i-snooze ka, talo ka". Ang sinumang empleyado ay maaaring kumuha ng mapagkukunan na kailangan ng lahat para sa kanilang trabaho, at sa gayon ay malalagay sa panganib ang iba pang mga empleyado at ang kumpanya sa kabuuan.

May kailangang gawin, kaya nagpasya ang boss na hatiin ang monolitikong kumpanya sa ilang mga departamento. Gumawa siya ng isang departamento ng pagpapadala, isang departamento ng marketing, isang departamento ng pagkuha, isang departamento ng pananalapi, at isang departamento ng imbentaryo. Hindi na maaaring kunin ng sinuman ang spaceship. Natanggap ng pinuno ng departamento ng pagpapadala ang lahat ng impormasyon tungkol sa mga paghahatid at inisyu ang barko sa courier na may pinakamaraming kumikitang order. Bukod pa rito, hindi pinapayagan ng bodega ang mga courier na kunin lang ang anumang mga kalakal na gusto nila. Sa halip, ang pagpili ng mga produkto mula sa bodega ay naging isang kontroladong proseso. Ang departamento ng pananalapi ay hindi maglalabas ng mga pondo para sa isang kampanya sa marketing kung alam nitong may pagbili sa lalong madaling panahon. Ang bawat departamento ay may isang pampublikong mukha - ang pinuno ng departamento.Ang panloob na istraktura ng bawat departamento ay sariling negosyo. Kung gusto ng isang courier na makakuha ng mga produkto, pumunta siya sa manager ng warehouse, hindi sa warehouse. Kung may dumating na bagong order, natanggap ito ng pinuno ng departamento ng pagpapadala ( public-facing representative) at hindi ng isang courier ( someone not authorized to interact with the other departments).

Sa madaling salita, pinagsama-sama ng boss ang mga mapagkukunan at aksyon na kinasasangkutan ng mga mapagkukunan sa mga grupo (mga departamento) , at ipinagbawal din ang iba na makagambala sa mga panloob na istruktura ng mga departamento. Ang mga interdepartmental na pakikipag-ugnayan ay kailangang dumaan sa isang partikular na tao.

Mula sa punto ng view ng OOP , ito ay walang iba kundi ang paghahati ng programa sa mga bagay. Ang isang monolitikong programa ng mga pamamaraan at mga variable ay nagiging isang programa na binubuo ng mga bagay. At ang mga bagay ay may mga variable at pamamaraan.

Ang problema ay ang sinumang empleyado ay maaaring magtrabaho sa anumang mapagkukunan at magbigay ng mga utos sa sinumang iba pang empleyado, lahat nang walang pangangasiwa o kontrol. Nagpataw kami ng maliit na paghihigpit, ngunit nakamit ang higit na kaayusan. At mas nakontrol din namin ang lahat.

Ito ay divide-and-conquer sa pinakadalisay nitong anyo.

2. Paano nilikha ang mga programa

Gusto kong hawakan ang isa pang mahalagang punto na nagpapakita ng isa pang kalamangan ng OOP . Nakikita mo ba na ang mga programa ay mas katulad ng mga hayop kaysa sa mga gusali? Hindi sila itinayo. Lumaki na sila. Ang pag-unlad ay patuloy na pagbabago. Sa pagtatayo, maaari kang magkaroon ng magandang plano at sundin ito nang may katumpakan. Hindi ito ang kaso sa pagbuo ng software.

Kadalasan sa pagprograma, hindi mo magagawa ang isang bagay sa paraang orihinal na nilayon mo at kailangang mag-rework nang marami. Mas madalas na nagbabago ang mga kinakailangan ng customer.

Ngunit paano kung ang customer ay nagbigay ng isang napaka-tumpak na detalye? Iyon ay nagpapalala pa ng mga bagay. Tingnan kung ano ang nangyayari sa produkto sa paglipas ng panahon.

Ang tagumpay ng produkto ay hahantong sa customer na gustong maglabas ng bagong bersyon, at pagkatapos ay isa pa at isa pa. At, siyempre, ang kailangan mo lang gawin ay magdagdag ng "maliit na pagbabago" sa umiiral na produkto. Kaya makikita mo ang pagbuo ng produkto ay isang pagkakasunud-sunod ng patuloy na pagbabago. Ang sukat lamang ng oras ay naiiba. Ang isang bagong bersyon ay maaaring ilabas isang beses sa isang linggo, isang beses sa isang buwan o isang beses bawat anim na buwan.

At anong konklusyon ang maaari nating makuha mula sa lahat ng ito? Ang panloob na istraktura ng produkto ay kailangang mapanatili sa paraang nagbibigay-daan sa mga makabuluhang (at menor de edad) na pagbabago na magawa nang may kaunting reworking.

Pagkakaisa ng bagay

Ngunit ang paggawa nito ay mas mahirap kaysa sa pagpapasya na gawin ito. Sinabi na namin na ang isang programa ay binubuo ng mga bagay na nakikipag-ugnayan sa isa't isa. Iguhit natin sa pisara ang lahat ng bagay ng ating programa, na kumakatawan sa mga ito sa pamamagitan ng mga puntos. At gumuhit tayo ng mga arrow mula sa bawat bagay (punto) patungo sa lahat ng iba pang bagay (puntos) kung saan ito nakikipag-ugnayan.

Ngayon ay pagsasamahin natin ang mga bagay (puntos) sa mga pangkat. Dapat igrupo ang mga puntos kung ang mga koneksyon sa pagitan ng mga ito ay mas matindi kaysa sa mga may iba pang mga punto. Kung ang karamihan sa mga arrow mula sa isang punto ay napupunta sa iba pang mga punto sa sarili nitong grupo, kung gayon ang mga grupo ay nabuo nang tama. Sinasabi namin na ang mga punto sa loob ng isang pangkat ay may mataas na pagkakaisa habang ang mga puntos sa iba't ibang grupo ay may mas mababang pagkakaisa.

Prinsipyo ng loose-coupling

Mayroong "prinsipyo ng maluwag na pagkakabit". Ang isang programa ay nahahati sa ilang bahagi, na kadalasang mga layer. Ang lohika ng mga layer/bahagi na ito ay mahigpit na pinagsama sa kanilang panloob na istraktura at napakaluwag na pinagsama sa iba pang mga layer/bahagi. Ang mga pakikipag-ugnayan sa pagitan ng mga layer ay karaniwang napaka-regulated. Maaaring tumukoy ang isang layer sa pangalawang layer at gumamit lamang ng maliit na subset ng mga klase nito. Ito ang prinsipyo ng "paghahati sa kumpanya sa mga departamento" na nakita natin kanina, ngunit sa mas malaking sukat.

Ang resulta ay maaari nating muling ayusin ang isang departamento kung kinakailangan upang madagdagan ang pagiging epektibo nito at maaari tayong kumuha ng mas maraming tao para sa departamento, at hangga't hindi natin binabago ang protocol ng pakikipag-ugnayan sa ating iba pang mga departamento, ang lahat ng mga pagbabagong ginawa ay manatiling lokal. Walang sinuman ang kailangang mag-aral muli ng anuman. Hindi mo kailangang i-rework ang buong system. Ang bawat departamento ay maaaring gumawa ng ganitong uri ng panloob na pag-optimize kung ang mga mekanismo para sa interdepartmental na pakikipag-ugnayan ay mahusay na napili.

Napiling mabuti. Pero paano kung hindi sila mapili ng maayos? Pagkatapos ang kapasidad para sa pagbabago ay mabilis na naubos at kakailanganin mong gawing muli ang buong system. Ito ay kailangang gawin paminsan-minsan. Hindi mo mahuhulaan ang hinaharap, ngunit maaari mong panatilihing pinakamababa ang bilang ng mga redo.

Prinsipyo ng abstraction

Ang pagpili kung paano nakaayos ang mga departamento at kung paano sila nakikipag-ugnayan ay ang " prinsipyo ng abstraction ". Sa programming, ginagamit ito upang matukoy ang pinakamahusay na paraan upang hatiin ang isang programa sa mga bahaging bumubuo at kung paano dapat makipag-ugnayan ang mga bahaging iyon. Maaari naming muling ilapat ang prinsipyo, hatiin ang mga resultang bahagi sa mga bahagi, hanggang sa masira namin ang programa sa mga indibidwal na klase.

Ang pagtatago ng panloob na istraktura ng mga bahaging ito at mahigpit na nililimitahan ang mga pakikipag-ugnayan sa ibang mga bahagi ay encapsulation . Ang encapsulation at abstraction ay mga pundasyon ng OOP . Ang isang mabuting programa ay dapat sumunod sa dalawang prinsipyong ito. Sa hinaharap, titingnan natin ang iba pang mga prinsipyo at tuklasin kung anong mga benepisyo ang ibinibigay ng mga ito.