SOLID ano ang 5 mga prinsipyo ng object-oriented na programa

Solidong solidong mga numero ng geometriko
pagsasanay
1

Ang SOLID ay isang akronim, na tumutukoy sa limang mga prinsipyo ng disenyo na nakatuon sa object (OOD o OOP). Ito ang mga alituntunin na maaaring magamit ng mga developer upang lumikha ng software na madaling pamahalaan, mapanatili at palawigin. Ang pag-unawa sa mga konseptong ito ay gagawing mas mahusay na developer at makakatulong sa iyo na maiwasan ang mga problema sa pamamahala ng software. Ano ang ibig sabihin ng maging isang mahusay na programmer?

Sinumang may ilang karanasan sa pagprograma ng software ay humuhusga ng code ng software na isinulat ng iba, gamit ang mga parameter ng paghuhukom batay sa kanilang landas sa karera.

Sa kurso ng aking propesyonal na karera, kilala ko ang maraming mga developer, at nakita ko ang libu-libong mga linya ng code at kapag kailangan kong suriin ang kasanayan ng isang developer higit sa lahat ay tinitingnan ko ang dalawang kadahilanan:

  • Pagiging simple sa pagbabasa ng code;
  • Gaano kahusay na gumana ang kanilang code at magbabago sa paglipas ng panahon.

Sa kasamaang palad, mayroong ilang mga pangunahing kaalaman o alituntunin na ginagawang madali upang maging mas mahusay sa pag-coding.

ang akronim na SOLID ay nangangahulugang:
S: prinsipyo ng solong responsibilidad
O: prinsipyo na bukas-sarado
L: Liskov na prinsipyo ng pagpapalit
I: Prinsipyo ng paghihiwalay ng interface
D: Prinsipyo ng Inversion of Dependencies

Magsimula tayo sa pamamagitan ng pagtuklas sa unang alituntunin ng SOLID, katulad ng

Single Prinsipyo ng Responsibilidad

Ang isang klase (o modyul) ay dapat magkaroon ng isang dahilan lamang upang magbago, upang magbago.

Ang konsepto mismo ay napaka-simple, ngunit upang makamit ang pagiging simple na ito ang path ng pagpapatupad ay maaaring maging napaka-kumplikado. Ang isang klase ay dapat magkaroon lamang ng isang dahilan upang magbago.

Pero bakit? 

Bakit napakahalaga na magkaroon lamang ng isang dahilan upang magbago?

Halimbawa, kung may dalawang magkakaibang dahilan para sa pagbabago, maiisip na ang dalawang magkakaibang koponan ay maaaring gumana sa parehong code para sa dalawang magkakaibang kadahilanan. Ang bawat isa ay kailangang magpatupad ng kanilang sariling solusyon, na sa kaso ng isang pinagsamang wika (tulad ng C ++, C # o Java), ay maaaring humantong sa mga module na hindi tugma sa iba pang mga koponan o iba pang mga bahagi ng aplikasyon.

Isa pang halimbawa, kung gumagamit ka ng isang naisaling wika, maaaring kailanganin mong subukang muli sa parehong klase o module para sa iba't ibang mga kadahilanan. Nangangahulugan ito ng mas maraming trabaho, oras at pagsisikap para sa kontrol sa kalidad.

Ang pagkilala sa tanging tampok na dapat magkaroon ng isang klase o module ay mas kumplikado kaysa sa simpleng pagtingin sa isang checklist upang magpatakbo ng mga pagsubok. 

Ngunit subukan nating mag-isip mula sa isang hindi gaanong teknikal na pananaw, iyon ay, subukang pag-aralan natin ang gumagamit ng aming klase o module, iyon ang gagamit nito. Ang isang pangunahing aspeto na dapat nating laging tandaan, ay ang katunayan na ang mga gumagamit ng application o system na binuo namin na pinaglilingkuran ng isang partikular na module ay ang mga humiling ng mga pagbabago dito. Ang mga pinaglingkuran ay hihilingin na baguhin ang klase o modyul. 

Ang ilang mga halimbawa ng mga module at ang paggamit nito:

  • Modyul ng pagpapanatili: ang gumagamit ay binubuo ng mga administrator ng database at mga arkitekto ng software.
  • Module ng pag-uulat: ang gumagamit ay binubuo ng mga manggagawa sa opisina, mga accountant at produksyon.
  • Module ng pagkalkula ng pagbabayad para sa isang sistema ng pamamahala ng payroll: ang mga gumagamit ay maaaring magsama ng mga abugado, manager at accountant.
  • Module ng paghahanap ng teksto para sa isang sistema ng pamamahala ng library: ang gumagamit ay maaaring kinatawan ng librarian o ng mga bisita at customer ng silid-aklatan mismo.

Kaya't kung ang unang hakbang ay upang maghanap para sa mga artista o artista na may papel na interlocutor sa modyul, maaaring maging mahirap ang maiugnay ang mga indibidwal sa lahat ng mga tungkulin. Sa isang maliit na kumpanya, ang isang tao ay maaaring gumanap ng maraming tungkulin habang sa isang malaking kumpanya ay maaaring maraming tao na mayroong isang solong papel. 

Tila mas makatuwiran upang tukuyin ang mga tungkulin, sa halip na mga tao o gumagamit.

Samakatuwid:

  • tinutukoy ng gumagamit ng system ng software ang mga dahilan para sa pagbabago;
  • ang isang responsibilidad ay isang pamilya ng mga pagpapaandar na nagbibigay-kasiyahan sa mga pangangailangan ng isang partikular na artista, iyon ay, ng gumagamit ng system;
  • ang mga artista, ang gumagamit ay naging isang mapagkukunan ng pagbabago para sa pamilya ng mga pagpapaandar na dapat masiyahan ang pangangailangan ng gumagamit;
  • ang ebolusyon ng mga pangangailangan ng gumagamit, gumagabay sa ebolusyon ng pag-andar;

Mabilis na mga prinsipyo

Tingnan natin ang ilang mga halimbawa

Ipagpalagay na mayroon kaming isang klase ng Book na nag-encapsulate ng konsepto ng isang libro at ang pag-andar nito.

Book Book sa klase

    pagpapaandar getTitle () {

        ibalik ang "Isang Mahusay na Aklat";

    }

    pagpapaandar getAuthor () {

        ibalik ang "Alessandro Baricco";

    }

    pag-andar sa susunod na pahina () {

        // Susunod na pahina

    }

    pag-print printCurrent Page () {

        echo "nilalaman ng kasalukuyang pahina";

    }

}

Ito ay isang napaka-normal na klase. Mayroon kaming isang libro, at maaaring bigyan kami ng klase ng pamagat, maaari nila kaming bigyan ng may-akda, at maaari silang magpatuloy. Sa wakas, may kakayahan din itong i-print ang kasalukuyang pahina sa screen. 

Gayunpaman, mayroong isang maliit na problema. 

Pag-iisip tungkol sa mga artista na kasangkot sa pamamahala ng object ng Book, sino sila? 

Madali nating maiisip ang dalawang magkakaibang aktor dito: Pamamahala ng libro (tulad ng librarian) At Mekanismo ng pagsumite ng data (tulad ng kung paano namin nais maihatid ang nilalaman sa gumagamit: on-screen, graphic na interface ng gumagamit, interface ng gumagamit lamang ng teksto, marahil ay naka-print). 

Samakatuwid mayroon kaming dalawang magkakaibang mga aktor na nakikipag-ugnay sa klase.

Sa madaling sabi ang klase na ito ay gumagawa ng isang halo sa pagitan ng:

  • negosyo lohika sa 
  • ang presentasyon 

ito ay maaaring maging isang problema dahil lumalabag ito sa solong prinsipyo ng pananagutan (SRP). 

Paano natin mababago, paano natin mapapabuti ang code na ito upang igalang ang prinsipyo ng solong responsibilidad?

Tingnan ang sumusunod na code:

Book Book sa klase

    pagpapaandar getTitle () {

        ibalik ang "Oceano Mare";

    }

    pagpapaandar getAuthor () {

        ibalik ang "Alessandro Baricco";

    }

    pahina ng pag-andar ng pag-andar () {

        // Susunod na pahina

    }

    pagpapaandar getCurrentPage () {

        echo "nilalaman ng kasalukuyang pahina";

    }

}

interface Printer {

    printPage ng pag-andar ($ pahina);

}

nagpapatupad ang klase ng StampaLibro ng Printer {

    mga printPage ng pag-andar ($ pahina) {

        pahina ng echo $;

    }

}

 

nagpapatupad ang klase ng htmlPrinter ng Printer {

    mga printPage ng pag-andar ($ pahina) {

        echo ' '. $ pahina ' ';

    }

}

Ang napaka-simpleng halimbawa na ito ay nagpapakita kung paano paghiwalayin ang pagtatanghal mula sa lohika sa negosyo, at sa pagsunod sa SRP nag-aalok ito ng magagandang kalamangan sa kakayahang umangkop ng aming proyekto.

Tingnan natin ang isa pang halimbawa:

Ang isang halimbawang katulad ng sa itaas ay kapag ang isang bagay ay maaaring makatipid at makuha ang sarili mula sa pagtatanghal.

Book Book sa klase

    pagpapaandar getTitle () {

        ibalik ang "Oceano Mare";

    }

    pagpapaandar getAuthor () {

        ibalik ang "Alessandro Baricco";

    }

    pahina ng pag-andar ng pag-andar () {

        // Susunod na pahina

    }

    pagpapaandar getCurrentPage () {

        ibalik ang "nilalaman ng kasalukuyang pahina";

    }

    i-save ang function () {

        $ filename = '/ mga dokumento /'. $ this-> getTitolo (). '-'. $ this-> getAuthor ();

        file_put_contents ($ filename, serialize ($ ito));

    }

}

Tulad ng dati, dito rin natin makikilala ang iba't ibang mga artista tulad Pamamahala ng libro (tulad ng librarian) At pagtitiyaga. Kailan man nais naming baguhin ang paraan ng pagpunta sa bawat pahina, kailangan naming baguhin ang klase na ito. Maaari kaming magkaroon ng maraming mga kadahilanan para sa pagbabago.

Book Book sa klase

    pagpapaandar getTitle () {

        ibalik ang "Oceano Mare";

    }

    pagpapaandar getAuthor () {

        ibalik ang "Alessandro Baricco";

    }

    pahina ng pag-andar ng pag-andar () {

        // Susunod na pahina

    }

    pagpapaandar getCurrentPage () {

        ibalik ang "nilalaman ng kasalukuyang pahina";

    }

}

klase SimpleFilePersistence {

    pag-save ng function (Book $ book) {

        $ filename = '/ mga dokumento /'. $ book-> getTitle (). '-'. $ book-> getAuthor ();

        file_put_contents ($ filename, serialize ($ book));

    }

}

Ang paglipat ng pagpapatuloy na pagpapatakbo sa isa pang klase ay malinaw na magkakahiwalay ng mga responsibilidad at malaya tayong makipagpalitan ng mga pamamaraan ng pagtitiyaga nang hindi nakakaapekto sa aming klase sa Aklat. Halimbawa, ang pagpapatupad ng isang klase sa DatabasePersistence ay magiging walang halaga, at ang aming lohika sa negosyo na binuo sa paligid ng pagpapatakbo ng libro ay hindi magbabago.

Magpatuloy sa pamamagitan ng pagbabasa ng ikalawang prinsipyong Bukas / Sarado ->

1 komentaryo

-iwan Ng komento

Il tuo indirizzo email non sarà Nai-post. I Campi sono obbligatori contrassegnati *

prinsipyo ng liskov
pagsasanay
Prinsipyo ng Pagpapalit ng Liskov, pangatlong prinsipyo ng SOLID

Ang mga klase ng bata ay hindi dapat makaapekto o baguhin ang mga kahulugan ng uri ng magulang na klase. Ang konsepto ng prinsipyong ito ay ipinakilala ni Barbara Liskov sa isang pangunahing tono ng kumperensya noong 1987 at pagkatapos ay nai-publish sa isang artikulo kasama si Jannette Wing noong 1994. Ang kanilang orihinal na kahulugan…

uso sa marketing ng google
pagsasanay
Paano gamitin ang Google Trends para sa real-time na marketing

Ang isa sa pinakadakilang paghihirap na naranasan ng mga kumpanya noong 2020 ay ang pag-unawa sa kung aling mga sektor ng produkto ang nagkakaiba-iba ng kanilang negosyo: sa katunayan ang karamihan sa mga sektor ng industriya ay nagdusa ng mabibigat na epekto na halos imposible para sa mga kumpanya na tumagos sa kanila, lalo na bilang isang bagong manlalaro. Napakakaunting mga sektor ng pagmamanupaktura ...

diskarte sa intelligence ng negosyo
Mga pamamaraan
Mga diskarte para sa matagumpay na Business Intelligence

Ang pagbuo ng isang matagumpay na diskarte para sa iyong Business Intelligence ay nagsisimula sa isang wastong paningin ng mga layunin. Nakikita natin sa ibaba ang ilang mga pangunahing punto. Pagsusuri sa kasalukuyang sitwasyon Ito ay magiging isang malaking pagkakamali upang maliitin ang aspektong ito. Ang pagsusuri sa kasalukuyang sitwasyon ay nangangahulugang pag-aaral ng mga proseso, istraktura ...