Ek ontmoet gereeld ontwikkelaars wat nog nie van die SOLID-beginsels gehoor het nie (ons . — Transl.) of objekgeoriënteerde programmering (OOP), of het daarvan gehoor, maar gebruik dit nie in die praktyk nie. Hierdie artikel beskryf die voordele van OOP-beginsels wat die ontwikkelaar in sy daaglikse werk help. Sommige van hulle is welbekend, ander nie so baie nie, so die artikel sal nuttig wees vir beide beginners en ervare programmeerders.
Ons herinner: vir alle Habr-lesers - 'n afslag van 10 000 roebels wanneer jy inskryf vir enige Skillbox-kursus met behulp van die Habr-promosiekode.
Skillbox beveel aan: Opvoedkundige aanlyn kursus .
DROOG (Moenie jouself herhaal nie)
'N Redelik eenvoudige beginsel, waarvan die kern duidelik uit die naam blyk: "Moenie jouself herhaal nie." Vir 'n programmeerder beteken dit die behoefte om duplikaatkode te vermy, sowel as die geleentheid om abstraksie in hul werk te gebruik.
As daar twee herhalende afdelings in die kode is, moet hulle in een metode gekombineer word. As 'n hardgekodeerde waarde meer as een keer gebruik word, is dit die moeite werd om dit na 'n publieke konstante om te skakel.
Dit is nodig om die kode te vereenvoudig en dit makliker te maak om te onderhou, wat die hoofdoel van OOP is. Jy moet ook nie die unie oorbenut nie, aangesien dieselfde kode nie verifikasie met beide die OrderId en die SSN sal slaag nie.
Verander Encapsulation
Die meeste maatskappye se sagtewareprodukte ontwikkel voortdurend. Dit beteken dat veranderinge aan die kode aangebring moet word, dit moet ondersteun word. Jy kan jou lewe makliker maak deur inkapseling te gebruik. Dit sal jou toelaat om jou bestaande kodebasis doeltreffender te toets en te onderhou. .
As jy dan in Java skryf .
Die beginsel van openheid / nabyheid
Hierdie beginsel kan maklik onthou word deur die volgende stelling te lees: "Sagteware-entiteite (klasse, modules, funksies, ens.) moet oop wees vir uitbreiding, maar gesluit vir wysiging." In die praktyk beteken dit dat hulle kan toelaat dat hul gedrag verander word sonder om die bronkode te verander.
Die beginsel is belangrik wanneer veranderinge aan die bronkode kodehersiening, eenheidstoetsing en ander prosedures vereis. Kode wat die oop/geslote beginsel volg, verander nie wanneer dit uitgebrei word nie, so daar is baie minder probleme daarmee.
Hier is 'n voorbeeld van kode wat hierdie beginsel oortree.
As u iets daarin moet verander, sal dit baie tyd neem, aangesien alle afdelings van die kode wat 'n verband met die verlangde fragment het, verander moet word.
Terloops, openheid-gesloteheid is een van die beginsels van SOLID.
Enkelverantwoordelikheidsbeginsel (SRP)
Nog 'n beginsel uit die SOLID stel. Dit verklaar dat "daar maar een oorsaak is wat 'n verandering in klas veroorsaak." Die klas los net een probleem op. Dit kan verskeie metodes hê, maar elkeen van hulle word slegs gebruik om 'n algemene probleem op te los. Alle metodes en eienskappe moet slegs dit dien.
Die waarde van hierdie beginsel is dat dit die skakel tussen 'n enkele stuk sagteware en die kode losmaak. Deur meer as een funksionaliteit by 'n klas by te voeg, word 'n verband tussen die twee funksies bekendgestel. Dus, as jy een van hulle verander, is daar 'n groot kans om die tweede, wat verband hou met die eerste, te bederf. En dit beteken om die toetssiklusse te verhoog om alle probleme vooraf te identifiseer.
Afhanklikheidsinversiebeginsel (DIP)
Hierbo is 'n kodevoorbeeld waar AppManager afhanklik is van EventLogWriter, wat op sy beurt nou gekoppel is aan AppManager. As jy 'n ander manier nodig het om 'n kennisgewing te wys, of dit nou druk, SMS of e-pos is, moet jy die AppManager-klas verander.
Die probleem kan met DIP opgelos word. Dus, in plaas van AppManager, versoek ons 'n EventLogWriter, wat met die raamwerk ingevoer sal word.
DIP maak dit moontlik om individuele modules maklik met ander te vervang deur die afhanklikheidsmodule te verander. Dit maak dit moontlik om een module te verander sonder om die ander te beïnvloed.
Samestelling in plaas van oorerwing
Daar is twee hoof maniere om kode te hergebruik: oorerwing en samestelling, wat albei hul eie voordele en nadele het. Gewoonlik word die tweede een verkies omdat dit meer buigsaam is.
Samestelling gee jou die vermoë om die gedrag van 'n klas tydens looptyd te verander deur sy eienskappe te stel. By die implementering van koppelvlakke word polimorfisme gebruik, wat 'n meer buigsame implementering gee.
Selfs Effektiewe Java deur Joshua Bloch beveel aan om samestelling bo oorerwing te kies.
Barbara Liskov-vervangingsbeginsel (LSP)
Nog 'n beginsel uit die SOLID toolkit. Dit stel dat subtipes vervangbaar moet wees vir die supertipe. Dit wil sê, metodes en funksies wat met 'n superklas werk, moet sonder probleme met sy subklasse kan werk.
LSP word geassosieer met beide die enkelverantwoordelikheidsbeginsel en die gedeelde verantwoordelikheidbeginsel. As 'n klas meer funksionaliteit as 'n subklas verskaf, sal laasgenoemde nie sommige van die funksionaliteit ondersteun nie, wat hierdie beginsel oortree.
Hier is 'n stukkie kode wat LSP weerspreek.
Die area (Reghoek r) metode bereken die oppervlakte van 'n reghoek. Die program sal ineenstort nadat Square uitgevoer is, want Square is nie 'n Reghoek hier nie. Volgens die LSP-beginsel moet funksies wat verwysings na basisklasse gebruik, objekte van afgeleide klasse sonder bykomende instruksies kan gebruik.
Hierdie beginsel, wat 'n spesifieke definisie van 'n subtipe is, is voorgestel deur Barbara Liskov in 'n 1987-konferensie-hoofnota getiteld "Data-abstraksie en hiërargie," vandaar die naam daarvan.
Interface Separation Principle (ISP)
Nog 'n SOLIEDE beginsel. Daarvolgens moet 'n koppelvlak wat nie gebruik word nie, nie geïmplementeer word nie. Deur hierdie beginsel te volg, help die stelsel om buigsaam te bly en geskik vir herfaktorering wanneer veranderinge aan die bedryfslogika gemaak word.
Dikwels vind hierdie situasie plaas wanneer die koppelvlak verskeie funksies gelyktydig bevat, en die kliënt benodig net een daarvan.
Aangesien die skryf van 'n koppelvlak 'n moeilike taak is, sal dit 'n uitdaging wees om dit te verander nadat die werk voltooi is sonder om iets te breek.
Die voordeel van die ISP-beginsel in Java is dat alle metodes eers geïmplementeer moet word, en eers dan kan dit deur klasse gebruik word. Daarom maak die beginsel dit moontlik om die aantal metodes te verminder.
Programmering vir 'n koppelvlak, nie 'n implementering nie
Alles hier is duidelik uit die titel. Die toepassing van hierdie beginsel lei tot die skepping van buigsame kode wat met enige nuwe implementering van die koppelvlak kan werk.
Jy moet die koppelvlaktipe vir veranderlikes, terugkeertipes of die metode-argumenttipe gebruik. 'n Voorbeeld is om SuperClass eerder as SubClass te gebruik.
Dit is:
Lys nommers= getNumbers();
Maar nie:
ArrayList numbers = getNumbers();
Hier is 'n praktiese implementering van wat hierbo gesê is.
Delegasiebeginsel
'n Algemene voorbeeld is die equals() en hashCode() metodes in Java. Wanneer dit nodig is om twee voorwerpe te vergelyk, word hierdie aksie na die ooreenstemmende klas in plaas van die kliënt een gedelegeer.
Die voordeel van die beginsel is dat daar geen duplisering van kode is nie en dit relatief eenvoudig is om gedrag te verander. Dit is ook van toepassing op gebeurtenisafvaardiging.
Al hierdie beginsels laat jou toe om meer buigsame, pragtige en betroubare kode te skryf met hoë kohesie en lae koppeling. Natuurlik is teorie goed, maar vir 'n ontwikkelaar om werklik die kennis wat opgedoen is te begin gebruik, is oefening nodig. Die volgende stap na die bemeestering van die beginsels van OOP kan die studie van ontwerppatrone vir die oplossing van algemene sagteware-ontwikkelingsprobleme wees.
Skillbox beveel aan:
- Praktiese kursus .
- Toegepaste aanlyn kursus .
- Twee-jaar praktiese kursus .
Bron: will.com