Prinsippet om avhengighetsomvending

Et viktig utviklingsprinsipp er prinsippet om avhengighetsomvending [«Dependency inversion principle» (DIP) på engelsk] som gir dekobling av viktige programvarekomponenter, såkalte høynivåkomponenter.

I stedet for at disse skal konsumere mange små "arbeidskomponenter" (dvs. lavnivåkomponenter) direkte, for å fungere, velger man å heller gjøre seg avhengig av abstraksjoner. Dette gjelder begge typer komponenter, både lavnivå og høynivå. I praksis vil man da gjerne benytte grensesnitt.

DIP er det siste viktige designmønsteret i SOLID.

Prinsipp for grensesnittoppdeling

Et veldig fornuftig designmønster er prinsippet for grensesnittoppdeling [«Interface segregation principle» (ISP) på engelsk] som enkelt og greit sier at en klient/bruker ikke skal måtte være avhengig av metoder som ikke brukes.

For å løse dette problemet forholder man seg til oppdelte spesialiserte grensesnitt så vedkommende ikke påvirkes når annen funksjonalitet skal defineres og utvikles.

ISP er det fjerde viktige designmønsteret i SOLID.

Liskovs substitusjonsprinsipp

Et prinsipp som kan minne om Åpen/lukket-prinsippet er Liskovs substitusjonsprinsipp [«Liskov substitution principle» (LSP) på engelsk], men dette prinsippet handler egentlig mer om hva instanser av underklasser skal kunne gjøre.

Helt konkret sier prinsippet at hvis klasse B arver fra klasse A, så skal instanser av B kunne erstatte instanser av A, uten at dette byr på problemer.

Et mye brukt eksempel:

Hvis en klasse for (geometrisk) kvadrat arver fra en klasse for rektangel må man forholde seg til bredde og lengde selv om alle sider i et kvadrat er like lange. Dette blir litt kleint fordi det er sidelengde som burde vært brukt.

Hvis bredde og lengde likevel brukes er det naturlig at begge settes til samme verdi, men da kan ikke en kvadratinstans lenger erstatte en rektangelinstans. Og dette bryter da med Liskovs substitusjonsprinsipp.

LSP er det tredje viktige designmønsteret i SOLID.

Ettansvars-prinsippet

Ettansvars-prinsippet [som er «Single responsibility principle» (SRP) på engelsk] setter visse krav til enhver modul, klasse, funksjon, o.s.v. som har ansvar for hvordan noe skal fungere:

  1. Når modulen, klassen, funksjonen o.s.v. endres skal det bare være èn grunn til dette.
  2. Man har 100% ansvar for å få jobben gjort, derfor skal man "pakke inn" (dvs. enkapsulere) all funksjonalitet. Direkte hjelp fra utsiden skal ikke være nødvendig.

Hvis disse kravene innfris vil den aktuelle programkoden bli mer robust og lettforståelig.

SRP er det første viktige designmønsteret i SOLID.

Åpen/lukket-prinsippet

Åpen/lukket-prinsippet [som er «Open/closed principle» (OCP) på engelsk] sier at ferdige moduler, klasser, funksjoner o.s.v. bør være stengt for endringer, men åpen for utvidelser.

Forklaringen er enkel: Hvis en bestemt funksjonalitet er brukt mange ganger og den endres må man refaktorere all gammel kode som er avhengig av den, dette blir en (enorm) tidstyv. Man bør i stedet utvide med ekstra funksjonalitet.

OCP er det andre viktige designmønsteret i SOLID.

EtherChannel

Hva kan man gjøre hvis man sliter med treg overføringshastighet internt i et datanettverk uten å bruke mye penger på å oppgradere?

Vel, hvis man har nyere Cisco-utstyr kan man benytte en kjekk funksjonalitet som heter EtherChannel. Da øker man båndbredden ved å kombinere flere porter.

De nødvendige forutsetningene er som følger:

  • To stk. Cisco-bokser som begge støtter EtherChannel.
  • Ledige porter på begge bokser.
  • Tilgjengelig kabel eller anledning til å strekke ny(e).

Siden nettverkskabel ikke er dyrt eller vanskelig å terminere kan man fikse dette selv.

Unicast vs. multicast vs. broadcast

På et datanettverk kan man ha flere former for kringkasting:

  • Unicast – når man kontakter kun èn mottaker.
  • Multicast – for å kontakte flere/mange.
  • Broadcast – i de tilfeller når man trenger å kontakte absolutt alle.

I utgangspunktet vil en svitsj (dvs. «switch» på engelsk) tillate alle former for kringkasting, mens en ruter kun tillater unicast og multicast.

Det finnes også en fjerde type – «anycast». Her tar man kontakt med nærmeste node.

Hallo verden i Assembly

Et enkelt testprogram i assembly for å bli våt på beina:

; alt bak et semikolon er kommentar

section .data
   hallo: db "Hallo, verden!",10
   ; db (som står for define bytes) benyttes for å opprette tekststrengen 'Hallo, verden!'
   ; etterpå følger tallet 10 for å få ett linjeskift
    
section .text
   global start

start:
   mov eax,4     ; signalkode for å skrive noe
   mov ebx,1     ; signalkode for standardutskrift (dvs. terminal)
   mov ecx,hallo ; man angir de ønskede dataene
   mov edx,15    ; man velger hvor mye av dataene som skal tas med
   int 80h       ; man forstyrrer systemet / ber om oppmerksomhet, for å få kjørt instruksjonene over

   mov eax,1     ; signalkode for å avslutte
   mov ebx,0     ; signalkode som sier at alt gikk greit
   int 80h       ; nytt kall til systemet for å kjøre nye instruksjoner (de to nye over)

Utskriften i terminalen blir som følger:

Hallo, verden!
   

Dette programmet kan f.eks. kjøres på rextester.com. Der benyttes NASM-assembleren så da slipper man å laste ned selv, ordne innholdet i fil, o.s.v.

Instruksjoner

Mange sier assemblyspråk er vanskelig, men hver type assemblyinstruksjon er faktisk veldig kortfattet og forståelig.

FASM

Nedenfor følger instruksjoner for FASM – en mye brukt assembler. Det finnes selvsagt alternative assemblere, da vil instruksjonene være litt annerledes.

mov

For å flytte (dvs. kopiere) data brukes instruksjonen mov:

mov destinasjon,kilde

Noen eksempler:

mov eax,8CBh
mov eax,edx
mov si,cx

Øverst er det verdien 8CBh som flyttes. Dette er en heksadesimalverdi da det er hengt på en h til slutt. For flytting av data mellom to forskjellige registre må begge registrene være av samme størrelse.

add

Om man skal legge sammen to verdier brukes add:

add destinasjon,kilde

Noen eksempler:

add eax,11b
add eax,edx
add si,cx

I øverste eksempel legges verdien 11b til verdien som allerede finnes i eax. Fordi det henger en b til slutt er dette et binærtall. Hvis man legger sammen registre må begge registrene være av samme størrelse, sånn som greia også er ved flytting.

sub

Motsetningen til add blir sub, for å trekke fra:

sub destinasjon,kilde

Noen eksempler:

sub eax,4h
sub cl,dl

Øverst trekkes 4h fra verdien som allerede finnes i eax. Størrelseskravet gjelder også her ved bruk av to forskjellige registre.

inc

Som et mulig alternativ til add har man inc:

inc destinasjon

Noen eksempler:

inc eax
inc cl
inc dl

Her inkrementeres verdien som allerede finnes i registeret, dvs. at den økes med 1.

dec

Motsetningen til inc blir dec:

dec destinasjon

Noen eksempler:

dec eax
dec cl
dec dl

Verdien som allerede finnes i registeret blir dekrementert, dvs. redusert med 1.

mul

Skal man multiplisere sammen to verdier bruker man mul og oppgir kun èn kilde:

mul kilde

Resten er allerede bestemt:

  • Kilde nr. 2 skal være al (8-bit), ax (16-bit) eller eax (32-bit).
  • Valgt kilde nr. 2 må være like stor som kilde nr. 1!
  • Destinasjonens størrelse blir dobbelt så stor som kildene. Så 8-bits kilder gir destinasjon som er 16-bit, o.s.v.
  • Mulige destinasjoner er
    • ah kombinert med al som sammen gir 16-bit.
    • dx kombinert med ax som sammen gir 32-bit.
    • edx kombinert med eax som sammen gir 64-bit.

Før mul kjøres må selvsagt begge kilder gis verdi – se komplett eksempel:

mov si,2h           ; verdi satt for første kilde
mov ax,11b          ; verdi satt for andre kilde
mul si              ; resultatet skal tilsvare 6 i desimaltallsystemet

OBS: mul foretar usignert multiplikasjon, for signert må imul brukes i stedet.

div

Som med multiplikasjon oppgir man kun èn kilde for divisjon (div):

div kilde        ; dette er nevner, altså den verdien det skal deles på

Resten er bestemt og ganske likt som for mul:

  • Den andre kilden (dvs. teller) blir en av
    • ah kombinert med al som sammen gir 16-bit.
    • dx kombinert med ax som sammen gir 32-bit.
    • edx kombinert med eax som sammen gir 64-bit.
  • Delregistrene over benyttes også for å lagre resulterende kvotient og rest
    • Rest lagres øverst, i ah (8-bit), dx (16-bit) eller edx (32-bit).
    • Kvotient lagres nederst, i al (8-bit), ax (16-bit) eller eax (32-bit).

Før div kjøres må selvsagt begge kilder ha verdi – se eksempel:

mov si,2h           ; verdi satt for nevner
mov eax,110b        ; verdi satt for teller
div si              ; resultatet skal tilsvare 3 i desimaltallsystemet

OBS: Som med mul jobber også div usignert, man har da idiv hvis man ønsker signert.

TBC