Objektorientert design - Object-oriented design

Objektorientert design er prosessen med å planlegge et system med samhandlende objekter for å løse et programvareproblem. Det er en tilnærming til programvaredesign .

Oversikt

Et objekt inneholder innkapslede data og prosedyrer gruppert sammen for å representere en enhet. Objektgrensesnittet definerer hvordan objektet kan samhandles med. Et objektorientert program beskrives av samspillet mellom disse objektene. Objektorientert design er disiplinen å definere objektene og deres interaksjoner for å løse et problem som ble identifisert og dokumentert under objektorientert analyse .

Det som følger er en beskrivelse av den klassebaserte delmengden av objektorientert design, som ikke inkluderer objektprototypebaserte tilnærminger der objekter vanligvis ikke oppnås ved å instantiere klasser, men ved å klone andre (prototype) objekter. Objektorientert design er en designmetode som omfatter prosessen med objektorientert nedbrytning og en notasjon for å skildre både logiske og fysiske samt statlige og dynamiske modeller av systemet som er under design.

Objektorienterte designemner

Input (kilder) for objektorientert design

Inputen for objektorientert design er levert av output fra objektorientert analyse . Innse at en utgangsartefakt ikke trenger å bli fullstendig utviklet for å fungere som innspill i objektorientert design; analyse og design kan skje parallelt, og i praksis kan resultatene av den ene aktiviteten mate den andre i en kort tilbakemeldingssyklus gjennom en iterativ prosess. Både analyse og design kan utføres trinnvis, og gjenstandene kan dyrkes kontinuerlig i stedet for å bli fullstendig utviklet i ett skudd.

Noen typiske inngangsartefakter for objektorientert design er:

  • Konseptuell modell : Resultatet av objektorientert analyse, den fanger opp begreper i problemdomenet . Den konseptuelle modellen er eksplisitt valgt til å være uavhengig av implementeringsdetaljer, for eksempel samtidighet eller datalagring.
  • Brukstilfelle : En beskrivelse av hendelser som sammen, fører til at et system gjør noe nyttig. Hver brukstilfelle gir ett eller flere scenarier som formidler hvordan systemet skal samhandle med brukerne som kalles aktører for å oppnå et bestemt forretningsmål eller -funksjon. Aktører i brukstilfeller kan være sluttbrukere eller andre systemer. I mange tilfeller blir brukstilfeller ytterligere utdypet i diagrammer for brukstilfeller . Bruk case -diagrammer brukes til å identifisere aktøren (brukere eller andre systemer) og prosessene de utfører.
  • System sekvensdiagram : Et systemsekvensdiagram (SSD) er et bilde som viser hendelser som eksterne aktører genererer, deres rekkefølge og mulige hendelser mellom systemet for et bestemt scenario av et brukstilfelle.
  • Brukergrensesnittdokumentasjoner (hvis aktuelt): Dokument som viser og beskriver utseendet på sluttproduktets brukergrensesnitt. Det er ikke obligatorisk å ha dette, men det hjelper å visualisere sluttproduktet og hjelper derfor designeren.
  • Relasjonsdatamodell (hvis aktuelt): En datamodell er en abstrakt modell som beskriver hvordan data blir representert og brukt. Hvis en objektdatabase ikke brukes, bør relasjonsdatamodellen vanligvis opprettes før designet, siden strategien som er valgt for objektrelasjonell kartlegging, er en utgang fra OO-designprosessen. Imidlertid er det mulig å utvikle relasjonsdatamodellen og de objektorienterte designartefaktene parallelt, og veksten av en artefakt kan stimulere foredling av andre gjenstander.

Objektorienterte konsepter

De fem grunnleggende konseptene for objektorientert design er funksjonene på implementeringsnivå som er innebygd i programmeringsspråket. Disse funksjonene refereres ofte til med disse vanlige navnene:

  • Objekt/klasse : En tett kobling eller assosiasjon av datastrukturer med metodene eller funksjonene som virker på dataene. Dette kalles en klasse eller et objekt (et objekt er opprettet basert på en klasse). Hvert objekt har en egen funksjon. Det er definert av dets egenskaper, hva det er og hva det kan gjøre. Et objekt kan være en del av en klasse, som er et sett med objekter som er like.
  • Informasjon som skjuler seg : Muligheten til å beskytte noen av objektets komponenter mot eksterne enheter. Dette realiseres av språkord for å gjøre det mulig å erklære en variabel som privat eller beskyttet for den eierende klassen .
  • Arv : Muligheten for en klasse til å utvide eller overstyre funksjonaliteten til en annen klasse . Den såkalte underklassen har en hel seksjon som er avledet (arvet) fra superklassen, og deretter har den sitt eget sett med funksjoner og data.
  • Grensesnitt (objektorientert programmering) : Evnen til å utsette implementeringen av en metode . Muligheten til å definere funksjoner eller metoder signaturer uten å implementere dem.
  • Polymorfisme (spesifikt undertyping ): Evnen til å erstatte et objekt med dets subobjekter . Evnen til en objektvariabel til å inneholde, ikke bare det objektet , men også alle dets subobjekter .

Utforming av konsepter

  • Definere objekter mødre, lage klassediagram fra konseptuelt diagram : Vanligvis kartlegge enhet til klasse.
  • Identifisere attributter .
  • Bruk designmønstre (hvis aktuelt): Et designmønster er ikke et ferdig design, det er en beskrivelse av en løsning på et vanlig problem, i en kontekst. Den største fordelen med å bruke et designmønster er at det kan gjenbrukes i flere applikasjoner. Det kan også tenkes som en mal for hvordan du løser et problem som kan brukes i mange forskjellige situasjoner og/eller applikasjoner. Objektorienterte designmønstre viser vanligvis relasjoner og interaksjoner mellom klasser eller objekter, uten å spesifisere de siste applikasjonsklassene eller objektene som er involvert.
  • Definer applikasjonsrammeverk (hvis aktuelt): Applikasjonsrammeverk er vanligvis et sett med biblioteker eller klasser som brukes til å implementere standardstrukturen til et program for et bestemt operativsystem. Ved å samle en stor mengde gjenbrukbar kode i et rammeverk, spares mye tid for utvikleren, siden han/hun blir spart oppgaven med å skrive om store mengder standardkode for hver ny applikasjon som utvikles.
  • Identifiser vedvarende objekter/data (hvis aktuelt): Identifiser objekter som må vare lenger enn en enkelt kjøretid for programmet. Hvis en relasjonsdatabase brukes, kan du designe objektrelasjonskartlegging.
  • Identifiser og definer eksterne objekter (hvis aktuelt).

Utdata (leveranser) av objektorientert design

Et sekvensdiagram viser, som parallelle vertikale linjer, forskjellige prosesser eller objekter som lever samtidig, og, som horisontale piler, meldingene som utveksles mellom dem, i rekkefølgen de oppstår.
  • Klassediagram : Et klassediagram er en type statisk struktur UML -diagram som beskriver strukturen i et system ved å vise systemets klasser, deres attributter og forholdet mellom klassene. Meldinger og klasser identifisert gjennom utviklingen av sekvensdiagrammer kan tjene som input til den automatiske generasjonen av det globale klassediagrammet til systemet.

Noen designprinsipper og strategier

  • Avhengighetsinjeksjon : Den grunnleggende ideen er at hvis et objekt er avhengig av å ha en forekomst av et annet objekt, blir det nødvendige objektet "injisert" i det avhengige objektet; for eksempel å bli sendt en databasetilkobling som et argument til konstruktøren i stedet for å lage en internt.
  • Asyklisk avhengighetsprinsipp : Avhengighetsgrafen til pakker eller komponenter (detaljene avhenger av arbeidsomfanget for en utvikler) bør ikke ha sykluser. Dette er også referert til som å ha en rettet asyklisk graf . For eksempel er pakke C avhengig av pakke B, som avhenger av pakke A. Hvis pakke A også var avhengig av pakke C, ville du ha en syklus.
  • Sammensatt gjenbruksprinsipp : Favoriser polymorf sammensetning av objekter fremfor arv.

Se også

Referanser

Eksterne linker