Skille mellom oppgaver

Diagram som illustrerer prinsippet om skille mellom oppgaver, som sier at en utførende entitet bare kan inneholde en enkelt type oppgaver

Innen informatikk er skille mellom oppgaver[1] et designprinsipp for å dele et dataprogram i forskjellige deler. Hver del fokuserer på et særskilt oppgaveområde, som vil en mengde informasjon som påvirker koden til et dataprogram. En oppgave kan være så generell som "maskinvaredetaljene for en applikasjon", eller så spesifikk som "navnet på hvilken klasse som skal instansieres". Et program som skiller bra mellom oppgave kalles et modulært[2] program. Modularitet, og dermed godt oppgaveskille, oppnås ved å innkapsle informasjon i en del av koden som har et godt definert grensesnitt. Innkapsling er et middel for å skjule informasjon.[3] Lagvise design i informasjonssystemer er et annet eksempel på skille mellom oppgaver (for eksempel oppdeling i presentasjonslag, forretningslogikklag, datatilgangsslag, persistenslag).[4]

Skille mellom oppgaver resulterer flere frihetsgrader for noen aspekter av et programmet sitt design, utbredelse eller bruk. Dette resulterer i økt frihet for forenkling og vedlikehold av kode. Når oppgavene er godt skilte vil det være flere muligheter for oppgraderinger, gjenbruk og uavhengig utvikling av moduler. Skjuling av implementeringsdetaljer til moduler bak et grensesnitt gjør det mulig å forbedre eller endre enkeltoppgaver uten å kjenne til detaljene til andre deler, og uten å måtte gjøre tilsvarende endringer i de andre delene. Moduler kan også eksponere ulike versjoner av et grensesnitt, hvilket som øker friheten til å oppgradere et komplekst system i små steg uten midlertidig tap av funksjonalitet.

Skille mellom oppgaver er en form form for abstraksjon. Som med de fleste abstraksjoner betyr skille mellom oppgaver å legge til ekstra kodegrensesnitt, hvilket generelt skaper mer kode som må kjøres. Den ekstra koden for adskillelse kan føre til høyere beregningskostnad, men kan på den andre siden også føre til gjenbruk av mer optimalisert kode

Anvendelse

Mekanismer for modulær eller objektorientert programmering i programmeringsspråk er mekanismer som gjør det mulig for utviklere å implementere skille mellom oppgaver. For eksempel kan objektorienterte språk som C#, C++, Delphi og Java skille mellom ooogaver ved hjelp av objekter, og arkitekturmønstre som modell–visning–kontroller (MVC) eller modell–visning–presentatør (MVP) kan skille mellom presentasjon og databehandling. Tjenesteorientert design kan skille oppgaver ut til ulike tjenester. Prosedyriske programmeringsspråk som C og Pascal kan skille ut oppgaver i prosedyrer eller funksjoner. Aspektorienterte programmeringsspråk kan skille bekymringer i aspekter og objekter.

Skille mellom oppgaverer også et viktig designprinsipp på mange andre områder, som for eksempel i byplanlegging, arkitektur og informasjonsdesign.[5] Målet er å forstå, designe og administrere komplekse, gjensidig avhengige systemer mer effektivt slik at funksjoner kan gjenbrukes, optimeres uavhengig av andre funksjoner, og isoleres fra potensiell svikt hos andre funksjonaliteter.

Vanlige eksempler er å skille et område i rom slik at aktiviteten i et rom ikke påvirker folk i andre rom, eller å koble en elektrisk ovn på en annen kurs enn belysningen slik ikke lyset går dersom sikring til ovnen ryker. Eksemplet med rom viser også innkapsling, hvor informasjon inni et rom (for eksempel hvor rotete det er) ikke er tilgjengelig for de andre rommene, bortsett fra gjennom grensesnittet (som er døren). Eksemplet med elektriske kurser viser at aktiviteten i en modul (som er en krets med påkoblede forbrukere av strøm) ikke påvirker aktiviteten i et annet modul, slik at hver modul ikke trenger å bry se med hva som skjer i den andre.

Se også

Referanser

  1. ^ Stig Ellingsen, Signe-Marie Hernes Bjerke, David English, Jon Iden. «ITIL-ordliste og forkortelser på norsk» (PDF). AXELOS Limited, 2011. «skille mellom oppgaver (separation of concerns, SoC): En tilnærming til å utvikle en løsning eller en IT-tjeneste som deler problemet inn i deler som kan løses uavhengig av hverandre. Denne tilnærmingen skiller ”hva” som skal gjøres fra ”hvordan” det skal gjøres.» 
  2. ^ Laplante, Phillip. What Every Engineer Should Know About Software Engineering. CRC Press. ISBN 978-0-8493-7228-5. 
  3. ^ Mitchell, R. J. Managing Complexity in Software Engineering. IEE. s. 5. ISBN 0-86341-171-1. 
  4. ^ Microsoft Application Architecture Guide. Microsoft Press. ISBN 978-0-7356-2710-9. 
  5. ^ Garofalo, Raffaele. Building Enterprise Applications with Windows Presentation Foundation and the Model View ViewModel Pattern. Microsoft Press. s. 18. ISBN 978-0-7356-5092-3.