122 lines
8.9 KiB
Markdown
122 lines
8.9 KiB
Markdown
---
|
|
title: "Bygg solide applikasjoner med objekt-orienterte prinsipper og praksiser"
|
|
date: 2023-05-13T11:28:45+02:00
|
|
description: ""
|
|
tags: ["NO", "Systemutvikling", "Objekt-orienterte prinsipper & praksiser"]
|
|
draft: false
|
|
showToc: 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**)](https://insidecreative.no/services/hjemmeside-for-bedrifter/systemutvikling/)
|
|
|
|
### 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**)](https://www.businessanalystlearnings.com/ba-techniques/2017/8/8/an-introduction-to-object-oriented-analysis)
|
|
|
|
### 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**)](https://www.youtube.com/watch?v=fJW65Wo7IHI)
|
|
|
|
### 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**)](https://www.youtube.com/watch?v=fGNF6wuD-fg)
|
|
|
|
#### ⤷ 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**)](https://effectivesoftwaredesign.com/2015/04/22/do-solid-design-principles-make-code-slow/)
|
|
|
|
#### ⤷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.
|