SOLID-periaatteiden ymmärtäminen

SOLID-periaatteet ovat viisi objektisuuntautunutta suunnitteluohjetta, jotka auttavat kehittäjiä luomaan järjestelmiä, jotka ovat helpompia ylläpitää, laajentaa ja testata. Robert C. Martin otti ne käyttöön 2000-luvun alussa ja ovat sittemmin tulleet nykyaikaisen ohjelmistoarkkitehtuurin kulmakiveksi.

  • Yhden vastuun periaate (SRP):[] Luokalla pitäisi olla vain yksi syy muutokseen, mikä tarkoittaa, että sen pitäisi olla vastuussa yhdestä toiminnallisuudesta.
  • Avoin/suljettu periaate (OCP):[ Luokat olisi avattava laajennusta varten, mutta suljettu muuttamista varten .
  • Liskov-korvausperiaate (LSP): Alatyyppien on oltava perustyyppiensä osalta vaihdettavissa järjestelmän rikkomatta järjestelmää.
  • Interface Segregation Principle (ISP):[ Asiakkaita ei pitäisi pakottaa riippumaan käyttöliittymistä, joita he eivät käytä; parempi on monia pieniä, erityisiä rajapintoja kuin yksi suuri yleiskäyttöinen käyttöliittymä.
  • Dependency Inversion Principle (DIP):[] Korkean tason moduulit eivät saisi olla riippuvaisia matalan tason moduuleista; molempien pitäisi riippua abstraktioista. Abstraktioiden ei pitäisi riippua yksityiskohdista .

UML:n rooli ohjelmistoarkkitehtuurissa Visualisointi

Yhtenäistetty mallinnuskieli (UML) tarjoaa standardoidun notaation järjestelmän suunnittelun visualisoimiseksi. Kaaviot toimivat yhdessä kehittäjien, arkkitehtien ja sidosryhmien kesken, mikä helpottaa monimutkaisten rakenteiden kommunikointia. SOLID-yhteensopiviin arkkitehtuuriin sovellettuna UML-kaaviot paljastavat, kuinka hyvin suunnittelu noudattaa periaatteita ja korostaa alueita, jotka saattavat tarvita korjausta.

UML sisältää 14 kaaviotyypit, mutta merkittävin SOLID visualisointi ovat luokkakaaviot, komponenttikaaviot, sekvenssikaaviot ja pakettikaaviot. Jokainen kaaviotyyppi voi korostaa eri näkökohtia periaatteet . Esimerkiksi luokkakaaviot osoittavat luokkavastuut ja rajapinnat, kun taas osat kaaviot korostavat riippuvuussuunnat ja laaja-alaisuus pistettä.

UML-kaavioiden kartoitus jokaiselle solidisoituneelle periaatteelle

Yhden vastuun periaate ja luokkakaaviot

Luokat kaaviot ovat ihanteellisia tarkistaa SRP vaatimusten. Hyvin suunniteltu luokka kaavio näyttää kunkin luokan selkeät, kohdennetut ominaisuudet ja menetelmät. Jos luokka on useita velvollisuuksia, sen laatikko kaavio sisältää etuyhteydetön toiminta . punainen lippu SRP rikkomisia.

Esimerkiksi luokka nimeltä ...InvoiceManager. joka käsittelee sekä laskun laskentaa että sähköpostin lähettämistä rikkoo SRP. Luokkakaaviossa näyttäisi menetelmiä kuten ...calculateTotal() ... ja ...lähetäEmail()..................................................................................................................................................................................................

Avoimet/suljetut periaatteet ja osakuvat

Osakaaviot kuvaavat järjestelmän korkeaa tasoa ja osoittavat, miten komponentit (esim. moduulit, osajärjestelmät) liittyvät liitäntöihin. OCP:n noudattamiseksi komponenttien olisi paljastettava kiinteät rajapinnat ja sallittava uudet sovellukset muuttamatta olemassa olevia.

Vuonna osa kaavio, voit edustaa tätä käyttämällä edellyttäen ja vaaditut rajapinnat. .PaymentProcessor . Esimerkiksi komponentti, voi määritellä .Maksu. Uusi maksutavat (luottokortti, PayPal) lisätään erillisinä osina, jotka toteuttavat kyseisen käyttöliittymän. Kaaviossa tehdään selväksi, että ydinprosessori ei tarvitse muuttaa .

Liskov Korvausperiaate ja perimys hierarkiat

Luokkakaaviot perintösuhteet suoraan testata LSP. Jos alaluokka ohittaa perusluokan menetelmiä tavoilla, jotka rikkovat odotettua käyttäytymistä, hierarkia on epäilyttävä. UML avulla voit mallintaa ennakkoehtoja, post conditions, ja invariants käyttämällä rajoituksia (esim., muistiinpanoja tai OCL .

Klassinen LSP-rikkomus on ...Square. Luokka periytyy . Jos kaaviossa ...Square...jos ... ... ~ ~ ~ ~ ~ ~ korkeuden [) ] . se rikkoo myös ...sopimuksen. Kaaviossa pitäisi osoittaa, että ... ~ quare... ei ole todella substitutiivinen. Voit korjata tämän, saatat käyttää yhteistä ...Shape...rajapintaa, jossa on erillinen ....Rektangle. ja .............ja Square....................................................................................................

Liitäntäerotusperiaate ja rajapintakaaviot

UML voi malli rajapinnat nimenomaisesti käyttäen käyttöliittymä laatikoita (jossa on ...[<>. Voit valvoa ISP, luot useita pieniä rajapintoja sijaan yhden suuren käyttöliittymän. Kaavio paljastaa mitkä luokat riippuvat siitä, mitkä rajapinnat; jos luokka on käyttämättömät menetelmät käyttöliittymä, se on rikkomus.

Esimerkiksi, sijasta MultiFunction Printer. käyttöliittymän kanssa .print() ..., ..., ..., ..........................................................................................................................................................................................................................

Riippuvuus Inversioperiaate ja riippuvuuskaaviot

Sekä luokkakaaviot että pakettikaaviot voivat kuvata DIP-vaatimusten noudattamista. DIP toteaa, että korkean tason moduulit (esim., liiketoimintalogiikka) ei pitäisi riippua matalan tason moduuleista (esim., tietokanta ohjaimet).

Paketin riippuvuuskaaviossa voit näyttää riippuvuuden suunnan. Jos korkean tason paketti osoittaa suoraan matalan tason pakettiin, kaavio varoittaa DIP-rikkomuksesta. Ratkaisuna on ottaa käyttöön abstraktio (interface) korkean tason paketissa, jossa matalan tason paketti riippuu tästä käyttöliittymästä. Päivitetty kaavio näyttää käänteiset riippuvuussuhteet .

Parhaat käytännöt UML-kaavioiden luomiseksi SOLID-arkkitehtuuria varten

Noudata näitä ohjeita tuottaa puhtaat, informatiivinen UML kaavioita, jotka vahvistavat SOLID periaatteita:

  • Käytä stereotypioita ja muistiinpanoja:[ Käytä .[<>... >..[< >........................................................................................................................................................................................................
  • Pidä kaaviot keskittyneet:[] Yksi kaavio on käsiteltävä yksi periaate tai pieni joukko asiaan liittyviä periaatteita. Vältä craming jokainen luokka yhdeksi jättiläiskaavio.
  • Näytä vain relevantit suhteet:[ Näytä perintö, yhdistyminen, yhdistäminen ja riippuvuus nuolet siellä, missä niillä on merkitystä. Ylikuormitus etuyhteydettömillä nuolet hämärtää SOLID-vaatimusten noudattamista.
  • Korkeat rikkomukset:[ Käytä eri värejä tai katkottuja linjoja ongelmallisten suhteiden merkitsemiseen. Esimerkiksi punainen riippuvuusnuoli korkean tason koodista matalan tason koodiin voi merkitä DIP-rikkomuksen.
  • Iterate with refaktoring:[] Kun korjaat suunnittelu täyttää SOLID, päivittää kaaviot. UML on elävä esine . ... ~ kohdella sitä kumppani koodin, ei kerta-kaavio.

Yhteinen pitfalls ja miten välttää niitä

Jopa kokeneet kehittäjät voivat joutua ansaan UML:n avulla SOLID-arkkitehtuurien suunnitteluun. Tässä on usein virheitä ja tapoja sivuuttaa ne:

  • Yli-abstrakti varhain:[ alkaen liian monet rajapinnat tai luokat voivat rikkoa YAFIGN (Et aio tarvita sitä). Aloita yksinkertainen luokkakaavio, sitten lisätä abstraktioita vain, jos tarvitaan SOLID periaatteet . tyypillisesti aikana refaktorointi.
  • UML-merkinnän yhdistäminen:[] Harhaanjohtava nuolinäppäin (esim. yleistysnuoli, jossa riippuvuusnuoli on oikea) voi johtaa väärintulkintaan. Tutkimus UML 2.5 erittely perusteet moniselitteisyyden välttämiseksi. [OMG UML-määrittely[ on lopullinen viite.
  • LSP:n huomiotta jättäminen sekvenssikaavioissa:[ Sarjakaaviot osoittavat ajoajan vuorovaikutusta. Jos alaluokkaesine korvataan perusluokan objekti ja vuorovaikutus muuttuu käyttäytymistä odottamatta, LSP on rikki. Validoidaan sekvenssit alaluokkatilanteissa.
  • Riippuvuussuuntaa ei oteta huomioon:[ DIP on riippuvuussuuntaa. Pakettikaavioissa aina vetää nuolia asiakkaasta palvelimelle. Jos näet syklit tai nuolet, jotka osoittavat väärään suuntaan, tee obstruktio.
  • Liian yksityiskohtaiset kaaviot:[ Luokkakaavio, jossa jokainen getter ja setter sotkee näkymän. Keskity julkisiin rajapintoihin ja avainsuhteisiin, jotka valvovat SOLID-periaatteita.

Työkalut UML-kaavioiden luomiseen

Useat työkalut voivat auttaa sinua luomaan UML kaavioita, jotka pysyvät synkronoitu koodin. Valitse yksi, joka sopii työnkulku:

  • PlantUML:[ Tekstipohjainen kaavionkäsittelytyökalu, joka integroituu versionhallintaan. Kirjoita selkeä tekstikuvaukset ja luo kaavioita automaattisesti. Ihanteellinen joukkueille, jotka haluavat kaavioita koodina. [Lue lisää PlantUML[.
  • Draw.io (diagrammit.net):[ Vapaa, web-pohjainen kaavioeditori. Tukee UML stensiilit ja helppo vienti. Hyvä yhteistyöhön whiteboarding.
  • Lucidchart:[ Maksullinen alusta UML-malleja ja reaaliaikaista yhteistyötä. Tarjoaa integrointi Confluence ja Jira.
  • Mallio:[] Avoimen lähdekoodin mallinnustyökalu, joka tukee UML:ää ja BPMN:ää. Voi luoda koodin luokkakaavioista ja käänteisen teknisen järjestelmän olemassa olevasta koodista.
  • IntelliJ IDEA Ultimate:[ Sisältää sisäänrakennetut kaaviointi ominaisuudet luokan, paketti, ja huoltokaaviot. Toimii suoraan koodipohjan live synkronointi.

Jotta voisit ymmärtää tarkemmin SOLID-periaatteita ja UML-integrointia, voit viitata Robert C. Martinin alkuperäiseen kirjoitukseen OOD:n (PDF) [ ja Wikipedia-artikkeliin .

Päätelmät

UML kaaviot muuntaa abstrakti SOLID periaatteet konkreettisiksi visuaalisia malleja, jotka kehittäjät voivat tarkastaa, keskustella ja parantaa. Kartoittamalla kunkin periaatteen sopiva kaaviotyyppi . Luokkakaavioita SRP ja ISP, komponentti kaavioita OCP ja DIP, ja perintö hierarkiat LSP . Voit järjestelmällisesti tarkistaa, että arkkitehtuuri pysyy joustava, ylläpidettävissä, ja skaalattavissa.

Avain on käyttää UML ei byrokraattinen esine, vaan elävä työkalu, joka kehittyy koodin. Yhdistettynä automatisoitu kaavion generointi ja säännölliset koodin arvostelut, UML tulee voimakas liittolainen rakentamisessa SOLID-yhteensopivia järjestelmiä, jotka kestävät ajan testi.