8.9 KiB
| title | date | description | tags | draft | showToc | |||
|---|---|---|---|---|---|---|---|---|
| Bygg solide applikasjoner med objekt-orienterte prinsipper og praksiser | 2023-05-13T11:28:45+02:00 |
|
false | true |
Introduksjon
I faget DAT109, "Systemutvikling", har vi gått igjennom temaer rundt det å utvikle systemer/applikasjoner, bruken av diverse utviklingsmetoder, og viktigheten med objekt-orientert analyse, utforming og programmering.
Her er en kort beskrivelse av faget:
Emnet skal gi studentene en innføring i prinsipper fra flere programvareutviklingsmetoder for utvikling av større programvaresystemer, samt. få erfaring i praktisk systemutvikling gjennom et større prosjektarbeid.
Sentralt er ulike utviklingsmetoder og modelleringsteknikker, modeller og notasjon.
Nå som det nærmer seg eksamen i dette faget har jeg valgt å gå igjennom hvert tema og skrive en bloggpost om disse for å få en bedre forståelse av disse. Mesteparten av infoen er hentet fra forelesningsnotater og slides.
Jeg har valgt å dele denne bloggposten opp i 5 deler, der jeg skal først introdusere litt om temaet for så å gå innom nøkkeltemaene objekt-orientert analyse (OOA) og objekt-orientert design (OOD) med designprinsippene GRASP og SOLID.
Systemutvikling (🖼️ - insidecreative.no)
Objekt-orienterte prinsipper og praksiser
Objekt-orientert programmering (OOP) har lenge vært en populær tilnærming av programvare. Dette er grunnet fordelene utviklere kan oppnå ved å organisere koden rundt konsepter som objekter og klasser. Når utviklere gjør dette vil de oppleve økt gjenbruk, fleksibilitet og lesbarhet i kodebasen, og dette fører til at programmet vil bli lettere å vedlikeholde og skalere.
Men (ja det er et "men"), det er ikke bare nok å følge OOP; det er viktig for utviklere å kjenne til og implementere velprøvde prinsipper og praksiser for å bygge solide systemer/applikasjoner.
I tillegg så finnes det ulemper med å bruke disse prinsippene og praksisene i programvareutvikling. En utvikler kan føle at dette er en ganske tidskrevende prosess ettersom det innebærer betydlig planlegging og dokumentasjon på forhånd, samt. at det kan bli økt kostnad i forhold til andre programvareutviklingsmetodologier grunnet akkurat dette.
OOA (🖼️ - businessanalystlearnings.com)
Objekt-Orientert Analyse (OOA)
Vi kan starte med en godt skrevet definisjon for OOA av Grady Booch:
Object-oriented analysis is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain
La oss si at vi skal utvikle et slags system, si et bibioteksystem. Ved å bruke OOA kan vi identifisere objekter som bøker, bibliotekarer, utlånere osv. og definere deres attributter og oppførsel.
Her bruker vi ulike modeller for å representere den statiske strukturen, dynamiske oppførselen og de funksjonelle kravene til systemet. Dette gjør det lettere for oss utviklere å forstå systemet, eller applikasjonen, og dens funksjonalitet før vi går videre til designfasen.
Noen av de vanligste modellene som brukes i OOA er deriblant klassediagrammer, use-case diagrammer, sekvensdiagrammer og tilstandsdiagrammer.
OOD (🖼️ - Derek Bananas on YouTube)
Objekt-Orientert Design (OOD)
Objekt-orientert design (OOD) er prosessen med å utforme løsningen for problemet som ble analysert i OOA, til et konkret design som er implementerbart.
Et vellykket OOD tar hensyn til prinsippene om lav kobling og høy sammenheng.
Fortsetter vi videre med eksempelet vårt over, biblioteksystemet, så kan vi designe klasser som "Bok", "Bibliotek", og "Bibliotekar" med tydelige ansvarsområder og godt definerte grensesnitt. Fordelene med dette er at koden vår blir mer modulær, vedlikeholdbar og enklere å teste.
Slik som OOA, bruker OOD også ulike modeller for å representere de ulike komponentene og interaksjonene i systemet, men disse er mer detaljrike og har flere implementasjonsspesifikke aspekter.
Noen av de vanligste modellene som brukes i OOD er deriblant klassediagrammer, samarbeidsdiagrammer, komponentdiagrammer og distribusjonsdiagrammer.
GRASP (🖼️ - ArjanCodes on YouTube)
⤷ General Responsibility Assignment Software Principles (GRASP)
GRASP er et sett med ni prinsipper / retningslinjer som hjelper oss med å tildele ansvar til klassene våre på en effektiv måte. Kort sagt et slags mentalt verktøysett.
Dette prinsippet hjelper oss å lage klasser som er uavhengige av hverandre, samtidig som de er sterkt knyttet til sine egne ansvarsområder.
Disse ni prinsippene / retningslinjene er følgende:
- Skaper (Creator)
- Informasjonsekspert (Information Expert)
- Lab kobling (Low Coupling)
- Høy samhørighet (High Cohesion)
- Kontroll / styringsenhet (Controller)
- Indireksjon (Indirection)
- Polymorfi (Polymorphism)
- Beskyttet mot variasjon (Protected Variations)
- Ren fabrikkering (Pure Fabrication)
Fortsetter vi med bibliotekeksempelet vårt, så bør "Bok" være ansvarlig for å håndtere bokrelaterte operasjoner, mens "Bibliotek" skal være ansvarlig for administrasjonen av bøker og utlånsprosessen.
Disse teknikkene har ikke blitt oppfunnet for å skape nye måter å jobbe på, men for å forbedre dokumentasjon og standardisere gamle, velprøvde programmeringsprinsipper i OOD.
Hver klasse vil ha en tydlig rolle og ansvaret vil være riktig fordelt, noe som resulterer i en mer fleksibel og vedlikeholdbar kodebase.
SOLID (🖼️ - effectivesoftwaredesign.com)
⤷SOLID
SOLID er også et akronym som GRASP, og står for fem viktige prinsipper innenfor objekt-orientert design. Disse fem prinsippene lyder slik:
- S ingle Responsibility
- prinsipp om at en klasse bør ha et ansvar og derfor bare en grunn til å endre seg.
- eksempel: Klassen "Bok" skal kun være ansvarlig for bokrelaterte operasjoner, som å lagre metadata, hente informasjon og håndtere status.
- O pen-Closed
- prinsipp om at en klasse skal være åpen for utvidelse, men lukket for endring.
- eksempel: For biblioteksystemet kan vi oppnå dette ved å bruke abstrakte klasser og grensesnitt, slik at nye typer bøker eller utlånsregler kan legges til uten å endre den eksisterende koden.
- L iskov Substitution
- prinsipp om at en subklasse bør kunne erstatte sin superklasse uten å bryte programmet.
- eksempel: Hvis vi har en superklasse "Item" som inkluderer både bøker og digitale ressurser, bær vi kunne bruke objekter av begge typene problemfritt i systemet.
- I nterface Segregation
- prinsipp om invertering av avhengigeter (riktig bruk av grensesnitt), mange spesifikke grensesnitt er bedre enn ett generelt grensesnitt.
- eksempel: Vi kan i biblioteksystemet vårt definere spesifikke grensesnitt for ulike roller, eksempelvis "Utlånbart" for bøker som kan lånes ut.
- D ependency Inversion
- prinsipp om invertering av avhengigeter (riktige koplinger, lav kopling), en klasse bør avhenge av abstraksjoner, ikke konkrete implementasjoner.
- Bruk av avhengighetsinjeksjon sikrer at klassene våres er avhengige av abstraksjoner heller enn konkrete klasser.
Ved å følge disse fem prinsippene kan man skrive høykvalitets, vedlikeholdbar kode og designe systemer på en riktig måte.
Konklusjon
Ved å bruke OOA og OOD kan utviklere få et grundigere og mer helhetlig bilde av systemet / applikasjonen de bygger, samtidig som de sikrer at koden deres er strukturert, fleksibel og enkel å vedlikeholde.
Disse spiller altså en avgjørende rolle i utviklingen av solide og vedlikeholdbare applikasjoner.
GRASP-prinsippene vil gi veiledning for riktig kobling og ansvarsfordeling mellom klassene våres.
SOLID-prinsippene vil gi en klar retning for å oppnå god designpraksis, med fokus på enkelt ansvar, åpen for utvidele og lukket for endring, substituerbarhet, grensesnitts-sergregasjon og avhengighetsinversjon.
Utviklere kan, ved å følge disse prinsippene / praksisene, skape programvareløsninger som er fleksible, skalerbare og enklere å vedlikeholde over tid. Dette gjør at utviklere får en solid grunnmur for å bygge komplekse systemer med en effektiv og strukturert utviklingsprosess.