Hiel faak moetsje ik ûntwikkelders dy't net heard hawwe fan 'e SOLID-prinsipes (wy . - Transl.) of objektrjochte programmearring (OOP), of hawwe der fan heard, mar brûke se net yn 'e praktyk. Dit artikel beskriuwt de foardielen fan OOP-prinsipes dy't de ûntwikkelder helpe yn syn deistich wurk. Guon fan harren binne goed bekend, oaren net sa folle, dus it artikel sil nuttich wêze foar sawol begjinners as erfarne programmeurs.
Wy herinnerje: foar alle Habr-lêzers - in koarting fan 10 roebel by it ynskriuwen fan in Skillbox-kursus mei de Habr-promoasjekoade.
Skillbox advisearret: Edukative online kursus .
DRY (Josels net werhelje)
In frij simpel prinsipe, de essinsje dêrfan is dúdlik út de namme: "Net werhelje dysels." Foar in programmeur betsjut dit de needsaak om dûbele koade te foarkommen, lykas de kâns om abstraksje te brûken yn har wurk.
As d'r twa werhelle seksjes yn 'e koade binne, moatte se kombineare wurde yn ien metoade. As in hurdkodearre wearde mear as ien kear brûkt wurdt, is it wurdich om it te konvertearjen nei in iepenbiere konstante.
Dit is nedich om de koade te ferienfâldigjen en makliker te ûnderhâlden, dat is it haaddoel fan OOP. Jo moatte de uny ek net oerbrûke, om't deselde koade gjin ferifikaasje sil trochjaan mei sawol de OrderId as de SSN.
Encapsulating Feroarings
De softwareprodukten fan 'e measte bedriuwen binne konstant yn ûntwikkeling. Dit betsjut dat feroarings moatte wurde makke oan de koade, it moat wurde stipe. Jo kinne jo libben makliker meitsje troch ynkapseling te brûken. Hjirmei kinne jo jo besteande koadebasis effisjinter testen en ûnderhâlde. .
As jo skriuwe yn Java, dan .
Iepen / sluten prinsipe
Dit prinsipe kin maklik wurde ûnthâlden troch it lêzen fan de folgjende útspraak: "Software-entiteiten (klassen, modules, funksjes, ensfh.) moatte iepen wêze foar útwreiding, mar sluten foar wiziging." Yn 'e praktyk betsjut dit dat se har gedrach feroarje kinne sûnder de boarnekoade te feroarjen.
It prinsipe is wichtich as feroarings oan 'e boarnekoade koadeferzje, ienheidstesten en oare prosedueres fereaskje. Koade dy't it iepen/sletten prinsipe folget, feroaret net by ferlinging, sadat der folle minder problemen mei binne.
Hjir is in foarbyld fan koade dy't yn striid is mei dit prinsipe.
As jo der wat yn moatte feroarje, sil it in protte tiid nimme, om't alle seksjes fan 'e koade dy't in ferbining hawwe mei it winske fragmint moatte wurde feroare.
Trouwens, iepenheid-slettenheid is ien fan 'e prinsipes fan SOLID.
Single Responsibility Principle (SRP)
In oar prinsipe út 'e SOLID set. It stelt dat "d'r mar ien oarsaak is dy't in feroaring yn 'e klasse feroarsaket." De klasse lost mar ien probleem op. It kin ferskate metoaden hawwe, mar elk fan har wurdt allinich brûkt om in mienskiplik probleem op te lossen. Alle metoaden en eigenskippen moatte tsjinje allinnich dit.
De wearde fan dit prinsipe is dat it losmakket de koppeling tusken de yndividuele software komponint en de koade. As jo tafoegje mear as ien funksjonaliteit oan in klasse, it yntrodusearret in relaasje tusken de twa funksjes. Sa, as jo feroarje ien fan harren, der is in grutte kâns fan ferneatigje de twadde, dy't ferbûn is mei de earste. En dit betsjut it fergrutsjen fan testsyklusen om alle problemen foarôf te identifisearjen.
Dependency Inversion Principle (DIP)
Hjirboppe is in koade foarbyld wêrby't AppManager hinget ôf fan EventLogWriter, dy't op syn beurt is nau keppele oan AppManager. As jo in oare manier nedich hawwe om in notifikaasje te sjen, of it no push, SMS of e-post is, moatte jo de AppManager-klasse feroarje.
It probleem kin wurde oplost mei help fan DIP. Dat, ynstee fan AppManager, freegje wy in EventLogWriter, dy't sil wurde ynfierd mei it ramt.
DIP makket it mooglik om maklik ferfange yndividuele modules mei oaren troch in feroaring fan de ôfhinklikens module. Dit makket it mooglik om ien module te feroarjen sûnder de oaren te beynfloedzjen.
Gearstalling ynstee fan erfskip
D'r binne twa wichtige manieren om koade opnij te brûken: erfskip en komposysje, dy't beide har eigen foardielen en neidielen hawwe. Gewoanlik wurdt de twadde de foarkar, om't it fleksibeler is.
Gearstalling jout jo de mooglikheid om it gedrach fan in klasse by runtime te feroarjen troch syn eigenskippen yn te stellen. By it útfieren fan ynterfaces wurdt polymorfisme brûkt, wat in fleksibeler ymplemintaasje jout.
Sels Effective Java troch Joshua Bloch advisearret komposysje te kiezen oer erfskip.
Barbara Liskov Substitution Principle (LSP)
In oar prinsipe út 'e SOLID toolkit. It stelt dat subtypen ferfangber wêze moatte foar it supertype. Dat is, metoaden en funksjes dy't wurkje mei in superklasse moatte sûnder problemen wurkje kinne mei syn subklassen.
LSP is ferbûn mei sawol it prinsipe fan ien ferantwurdlikens as it prinsipe fan dielde ferantwurdlikens. As in klasse jout mear funksjonaliteit as in subklasse, dan sil de lêste net stypje guon fan 'e funksjonaliteit, yn striid mei dit prinsipe.
Hjir is in stik koade dy't LSP tsjinsprekt.
De metoade fan gebiet (Rjochthoek r) berekkent it gebiet fan in rjochthoek. It programma sil crashe nei it útfieren fan Square omdat Square hjir gjin rjochthoek is. Neffens it LSP-prinsipe moatte funksjes dy't ferwizings brûke nei basisklassen objekten fan ôflaatklassen brûke kinne sûnder ekstra ynstruksjes.
Dit prinsipe, dat is in spesifike definysje fan in subtype, waard foarsteld troch Barbara Liskov yn in 1987 konferinsje keynote mei de titel "Data Abstraksje en Hierarchy," fandêr syn namme.
Interface Split Principle (ISP)
In oar SOLID prinsipe. Dêrnjonken moat in ynterface dy't net brûkt wurdt net ynfierd wurde. It folgjen fan dit prinsipe helpt it systeem fleksibel te bliuwen en geskikt foar refactoring as feroarings wurde makke oan 'e bestjoeringslogika.
Meast faak, dizze situaasje komt foar as de ynterface befettet ferskate funksjes tagelyk, en de klant moat mar ien fan harren.
Sûnt it skriuwen fan in ynterface in drege taak is, sil it feroarjen nei it wurk foltôge sûnder wat te brekken in útdaging wêze.
It foardiel fan it ISP-prinsipe yn Java is dat alle metoaden earst moatte wurde ymplementearre, en pas dan kinne se brûkt wurde troch klassen. Dêrom makket it prinsipe it mooglik om it oantal metoaden te ferminderjen.
Programming foar de ynterface, net de ymplemintaasje
Alles is hjir dúdlik út de namme. It tapassen fan dit prinsipe liedt ta it meitsjen fan fleksibele koade dy't kin wurkje mei elke nije ymplemintaasje fan 'e ynterface.
Jo moatte it ynterfacetype brûke foar fariabelen, returntypen, of it arguminttype metoade. In foarbyld is it brûken fan SuperClass ynstee fan SubClass.
Dat is:
List numbers= getNumbers();
Mar net:
ArrayList numbers = getNumbers();
Hjir is in praktyske ymplemintaasje fan wat hjirboppe besprutsen is.
Prinsipe fan delegaasje
In gewoan foarbyld is de metoaden equals () en hashCode () yn Java. As it nedich is om twa objekten te fergelykjen, wurdt dizze aksje delegearre oan de oerienkommende klasse ynstee fan de kliïnt ien.
It foardiel fan it prinsipe is dat der gjin duplikaasje fan koade is en it is relatyf ienfâldich om gedrach te feroarjen. It jildt ek foar evenemint delegaasje.
Al dizze prinsipes kinne jo skriuwe fleksibeler, moaie en betroubere koade mei hege gearhing en lege coupling. Fansels is teory goed, mar foar in ûntwikkelder om de opdien kennis feitlik te brûken, is praktyk nedich. Sadree't jo OOP-prinsipes behearskje, kin jo folgjende stap wêze om ûntwerppatroanen te learen om mienskiplike softwareûntwikkelingsproblemen op te lossen.
Skillbox advisearret:
- Praktyske kursus .
- Oanfrege online kursus .
- Twa jier praktyske kursus .
Boarne: www.habr.com