15 Videregående OOP

void tegn(); (evt. abstrakt)
void flytTil(x,y);
double areal(); (evt. abstrakt)

Nu kan Figur være superklassen, Punkt er-en Figur og arver derfor fra Figur og definerer tegn(), UdstraktFigur er-en Figur med en ekstra variabel og metode, Rektangel er-en UdstraktFigur udvidet med variablerne dx og dy og ligeledes med Trekant, der er-en UdstraktFigur udvidet med variablerne dx, dy, dx2 og dy2.

15.1.3 Øvelse

1. Kig på klassediagrammet for den kodenære tankegang. Hvor skulle cirkler placeres? ellipser? firkanter? polygoner? Tegn dem ind.

2. Kig på klassediagrammet for den analytiske tankegang. Hvor skulle cirkler placeres? ellipser? firkanter? polygoner? Tegn dem ind.

3. Hvordan adskiller diagrammerne sig? Hvilken tankegang kan du bedst lide? Hvorfor? Hvor er der mest kode? Hvilket klassediagram tror du er nemmest at udvide senere?

15.1.4 Nedarvinger, hvor funktionaliteten ikke udvides, men begrænses

Et dilemma i den analytiske tankegang er, hvad man skal stille op, når der konceptuelt er tale om en specialisering (som altså burde medføre arv), men hvor funktionaliteten begrænses i stedet for (som normalt) at blive udvidet.

Tænk f.eks. på cirkler og ellipser. Det er klart, at Ellipse skal have to variabler til at angive radius (højde og bredde), mens Cirkel kun har brug for én radius.

På den anden side er der ingen tvivl om, at en cirkel er en slags ellipse (en hel rund ellipse), så konceptuelt gælder relationen Cirkel 'er-en' Ellipse, selvom Ellipse-klassen har flere data end Cirkel.

15.2 Delegering (i stedet for arv)

Delegering: At et objekt har et andet objekt, som det 'uddelegerer' nogle opgaver til

Ofte har man brug for at udvide og genbruge en klasses funktionalitet. Den sædvanlige måde at gøre det på er, som bekendt, ved at lave en nedarving, men det kan være, at det (af den ene eller anden grund) er mere hensigtsmæssigt at bruge delegering i stedet.

Delegering går ud på at skrive klassen med ekstra funktionalitet, sådan at den bruger den oprindelige klasse i stedet for at arve fra den.

15.2.1 At skjule nogle metoder

Eksempelvis kan det være, man ønsker at 'arve' en klasses data, og nogle men ikke alle, dens metoder. Så vil delegering sandsynligvis være mere hensigtsmæssigt end nedarving.

Arv kan ikke skjule metoder, men det kan delegering

Man vil lave datastrukturen 'stak', som er en liste, hvor man kun kan tilføje og fjerne elementer fra den ene ende (lægge på og tage af stakken). Man kunne arve fra Vector:

public class StakMedNedarving extends java.util.Vector
{
  public void lægPå(Object o)
  {
    addElement(o);
  }

  public Object tagAf()
  {
    Object o = lastElement();
    setSize( size() - 1 );
    return o;
  }
}

... men hvordan kan man nu være sikker på, at de, der bruger StakMedNedarving, bruger de nye metoder?

De kunne godt kalde elementAt() eller nogen af de andre metoder som StakMedNedarving arver fra Vector, og der er ikke nogen elegant måde at forhindre det på.

Det er mere hensigtsmæssigt at delegere opgaven med at holde styr på listen til Vector i stedet for at arve fra Vector:

public class StakMedDelegering
{
  private java.util.Vector v = new java.util.Vector();

  public void lægPå(Object o)
  {
    v.addElement(o);
  }

  public Object tagAf()
  {
    Object o = v.lastElement();
    v.setSize( v.size() - 1 );
    return o;
  }
}

Nu er vektoren indkapslet i stakken, og det er umuligt at kalde andre metoder end dem, der er defineret i StakMedDelegering.

Det er sjældent en god idé at arve fra 'værktøjsklasser' såsom Vector: Man har nemlig ikke mulighed for at forhindre brugeren af den nye klasse i at kalde nogle metoder, det ikke var meningen, han skulle kalde.

StakMedNedarving er et eksempel på den 'kodenære' tankegang beskrevet i afsnit 15.1.1 og illustrerer et af problemerne med denne måde at tænke på.

I C++ kan problemet med at skjule superklassens metoder løses ved at bruge såkaldt "privat nedarving", hvor kun underklassen har adgang til de nedarvede metoder (så det virker, som om metoderne er erklæret private i den nedarvende klasse).

Forhindre metodekald ved at kaste undtagelser

En anden mulighed kunne være at tilsidesætte alle de nedarvede metoder, der var uønskede, med nogle nye, der konsekvent kaster en undtagelse (eng.: exception), hvis de bliver kaldt. Dette er naturligvis ikke specielt elegant, men fra tid til anden kan man blive tvunget ud i den løsning (et andet eksempel ses i afsnit 17.1.3, Gøre data uforanderlige vha. Proxy).

public class StakMedNedarvingKastUndtagelser extends java.util.Vector
{
  public void lægPå(Object o)
  {
    super.addElement(o);
  }

  public Object tagAf()
  {
    Object o = lastElement();
    setSize( size() - 1 );
    return o;
  }

  public void addElement(Object obj) {
    throw new UnsupportedOperationException("Ikke tilladt på en stak");
  }

  public void setSize(int newSize)   {
    throw new UnsupportedOperationException("Ikke tilladt på en stak");
  }
  
  public Object elementAt(int index) {
    throw new UnsupportedOperationException("Ikke tilladt på en stak");
  }

  public void setElementAt(Object obj, int index) {
    throw new UnsupportedOperationException("Ikke tilladt på en stak");
  }

  public void insertElementAt(Object obj, int index) {
    throw new UnsupportedOperationException("Ikke tilladt på en stak");
  }
  // osv...
}

En stor ulempe ved denne teknik er, at fejl først fanges på kørselstidspunktet i stedet for under oversættertidspunktet.

En anden ulempe er, at hver gang superklassen får defineret en ny metode, der ikke skal kunne kaldes i nedarvingen, skal man huske at opdatere nedarvingen tilsvarende. Vector er således blevet udvidet med et antal metoder fra JDK1.1 til JDK1.2 (f.eks. get(), add() og de andre metoder i interfacet List - se kapitel 1, Samlinger af data), og koden ovenfor skulle derfor udvides med disse metoder, da man skiftede til JDK1.2 (i øvrigt er de fleste af Vectors metoder erklæret final og kan derfor faktisk overhovedet ikke tilsidesættes i en nedarving).

15.2.2 Modellering af roller

Et andet tilfælde, hvor delegering er en bedre idé end arv, er, hvor objekterne kan have flere roller eller skifte rolle under udførelsen af programmet.

Arv er kun velegnet til "er-en"-relationer, der aldrig ændrer sig under kørslen

Lad os se på et eksempel inden for en virksomhed. Her er personer, der kan være ledere, ansatte og konsulenter (man kunne f.eks. forestille sig, at de har hver sin lønberegnings-metode, forskellige beføjelser, osv. ...).

Man kunne modellere rollerne med nedarving som vist i figuren herunder:

Rollerne modelleret med nedarving

Der er en fælles superklasse...

public class Person
{
  String fornavn;
  String efternavn;
  String cpr;

  public String hentFornavn() { return cpr; }

  // flere metoder og variabler...
}

... og nogle nedarvinger af Person, bl.a. lederen:

public class LederArv extends Person
{
  java.util.List ansatte;

  // opret en leder
  public LederArv() { }

  // opret en leder-rolle med en eksisteren person (ikke så elegant...)
  public LederArv(Person p)
  {
    this.fornavn   = p.fornavn;
    this.efternavn = p.efternavn;
    this.cpr       = p.cpr;
    // kopiér resten af Persons variabler her...
  }

  public java.util.List hentAnsatte() { return ansatte; }

  // flere metoder og variabler...
}

Problemerne med idéen om at bruge nedarving kan være at:

1. Personer kan i virkeligheden udfylde flere roller samtidigt.

2. Personer kan i virkeligheden skifte rolle.

Hvis objektet kan udfylde flere roller

Hvis kombinationer af rollerne kan opstå, sådan at f.eks. en person samtidig er konsulent (aflønningsmæssigt) og leder (m.h.t. Beføjelser), vil ingen af klasserne passe.

Skulle rollerne alligevel modelleres med roller, ville man blive nødsaget til at lave nye nedarvinger for kombinationsrollerne, f.eks. LederOgKonsulent og AnsatOgKonsulent.

Hvis objektet kan skifte rolle

Værre ser det ud, hvis objektet kan skifte rolle (f.eks. fra Ansat til Leder). Da man ikke kan lave om på et objekts type (klasse), når det først er oprettet, er der intet at gøre andet end at oprette et objekt med den nye rolle og kopiere alle fælles data (dem, der stammer fra Person-klassen) fra det oprindelige objekt til det nye.

Skal vi lave en Ansat om til en Leder, kan det altså kun ske ved at oprette en ny Leder og smide det gamle Ansat-objekt væk. Vi må så kode Leder's konstruktør til at kopiere de fælles data (og i øvrigt håbe på, at der ikke er en anden del af programmet, der ændrer i data, efter at vi har kopieret dem).

Situationen med delegering i stedet for arv

I stedet for arv kunne vi modellere rollerne med delegering som vist nedenfor. Nu har Leder, Ansat og Konsulent en reference til et Person-objekt, og alle metodekald, der har med personen at gøre, delegeres videre til Person-objektet.

Rollerne modelleret med delegering

public class LederDelegering
{
  private Person person;
  private java.util.List ansatte;

  // opret en leder
  public LederDelegering()
  {
    person = new Person();
  }

  // opret en leder-rolle med en eksisteren person (mere elegant)
  public LederDelegering(Person p)
  {
    person = p;
  }

  public String hentFornavn() { return person.hentFornavn(); } // delegér

  public java.util.List hentAnsatte() { return ansatte; }

  // flere metoder og variabler...
}

Det er let at lade en Person have flere roller samtidig: Så deles et Leder-objekt og et Konsulent-objekt om et fælles Person-objekt.

Det er også let at lade en Person skifte rolle: Skal vi lave en Ansat om til en Leder, kan det ske ved at oprette en ny Leder og lægge det eksisterende Person-objekt ind i det.

Bemærk, at Leder, Ansat og Konsulent nu ikke mere er af typen Person. Dette er ikke noget problem, hvis man (som eksemplet forudsætter) har separate lister af ledere, ansatte og konsulenter. Har man brug for en fælles superklasse, kunne man definere et interface (eller en abstrakt klasse) PersonIF, som de alle implementerede, og som havde de metoder der var fælles for ledere, ansatte og konsulenter.

15.2.3 Resumé og konklusion

15.3 Specificér funktionalitet i et interface

15.3.1 Repetition af interfaces

I generel sprogbrug er et interface (da.: snitflade) en form for grænseflade, som man gør noget gennem. F.eks. er en grafisk brugergrænseflade de vinduer med knapper, indtastningsfelter og kontroller, som brugeren har til interaktion med programmet.

Vi minder om, at en klasse er definitionen af en type objekter. Her kunne man opdele i

1. Grænsefladen - hvordan objekterne kan bruges udefra.
   Dette udgøres af navnene³ på metoderne, der kan ses udefra.

2. Implementationen - hvordan objekterne virker indeni.
   Dette udgøres af variabler og programkoden i metodekroppene.

Et 'interface' svarer til punkt 1): En definition af, hvordan objekter bruges udefra. Man kan sige, at et interface er en "halv" klasse.

Et interface er en samling navne på metoder (uden krop)

Et interface kan implementeres af en klasse - det vil sige, at klassen definerer alle interfacets metoder sammen med programkoden, der beskriver, hvad der skal ske, når metoderne kaldes.

15.3.2 Eksempel: Stak

Grænsefladen til stakken (beskrevet i afsnit 15.2) kunne være defineret i et interface:

public interface Stak
{
  public void lægPå(Object o);
  public Object tagAf();
}

Der kan være mange klasser, der implementerer Stak, f.eks. de to fra forrige afsnit:

public class StakMedNedarving2 extends java.util.Vector implements Stak
{
  public void lægPå(Object o)
  {
    addElement(o);
  }

  public Object tagAf()
  {
    Object o = lastElement();
    setSize( size() - 1 );
    return o;
  }
}

og:

public class StakMedDelegering2 implements Stak
{
  private java.util.Vector v = new java.util.Vector();

  public void lægPå(Object o)
  {
    v.addElement(o);
  }

  public Object tagAf()
  {
    Object o = v.lastElement();
    v.setSize( v.size() - 1 );
    return o;
  }
}

Et enkelt sted i programmet er det nødvendigt at beslutte, hvilken implementation af Stak der anvendes, nemlig når objektet oprettes:

  Stak s = new StakMedNedarving2();

Resten af programmet arbejder bare med objekter af typen Stak uden at vide noget om, hvordan de er implementeret, f.eks.:

  ...
  System.out.print( s.tagAf() );
  System.out.print( s.tagAf() );
  fyldStakkenOp(s);
  ...

Også metoder, f.eks. fyldStakkenOp(), kan arbejde på ethvert objekt, der implementerer Stak-interfacet:

  public void fyldStakkenOp(Stak s)
  {
    s.lægPå("Hej");
    s.lægPå("med");
    s.lægPå("dig");
  }

Her er et klassediagram, der illustrerer, hvordan en klient (en klasse eller et program) benytter noget funktionalitet beskrevet i Stak. Metoder er ikke vist i diagrammet.

Pilen fra Klient til Stak viser, at klienten har en instans af Stak (en variabel af type Stak, der jo kan pege på alle objekter, der implementerer Stak-interfacet).

Stakimpl1 og Stakimpl2 er to klasser, der implementerer Stak-interfacet⁴ (nedarvingspilen er tegnet med stiplet linje for at markere, at der er tale om implementation af interface, ikke nedarving), f.eks.: StakMedNedarving og StakMedDelegering.

15.3.3 Eksempel: Collections-klasserne

Funktionaliteten i datastrukturerne i Collections-klasserne er alle specificerede i interfaces, og brugeren opfordres til at henvise så lidt til implementationerne (som f.eks. ArrayList og LinkedList) som muligt og så meget til interfacene (som f.eks. List) som muligt:

  List l = new ArrayList();
  
  // ... resten af programmet arbejder bare med en List-variabel
  //     uden at kende til den konkrete implementation af listen

Det gør det lettere senere at udskifte implementationen af datastrukturen med en anden med samme funktionalitet, men anderledes indre struktur, f.eks. udskifte ArrayList med LinkedList:

  List l = new LinkedList();
  
  // ... resten af programmet arbejder bare med en List-variabel
  //     uden at kende til den konkrete implementation af listen

Se også afsnit 1.1.2, Interfacene til lister og mængder.

15.4 Konstanterklæringer i et interface

Det følgende er et lille fif i Java, der kan gøre programkoden mere læselig (i C++ har man mulighed for at erklære globale konstanter, så her er fiffet ikke relevant):

Ved at erklære konstanter, der skal bruges fra flere klasser i et interface, kan klasser, der har brug for disse konstanter, implementere interfacet og derefter bruge konstanterne uden at skulle skrive et klassenavn foran.

Eksempelvis kunne vi definere et interface med nogle tilstande:

public interface Tilstandsliste
{
  int IKKE_STARTET = 0;
  int STARTER = 1;
  int I_GANG = 2;
  int STOPPER = 3;
  int STOPPET = 4;
}

Bemærk, at variabler i et interface automatisk erklæres public static final (klassevariabel, der kan aflæses af alle, men ikke ændres).

Nu kunne vi selvfølgelig bruge konstanterne, som man plejer, ved at skrive klassen foran:

public class BenytTilstande1
{
  public static void main(String[] args)
  {
    int tilstand = Tilstandsliste.IKKE_STARTET;

    while (tilstand != Tilstandsliste.STOPPET) {
      System.out.println("tilstand = "+tilstand);
      tilstand++;
    }
  }
}

... men i klasser, der implementerer Tilstandsliste, kan det skrives kortere:

public class BenytTilstande2 implements Tilstandsliste
{
  public static void main(String[] args)
  {
    int tilstand = IKKE_STARTET;
    
    while (tilstand != STOPPET) {
      System.out.println("tilstand = "+tilstand);
      tilstand++;
    }
  }
}

15.5 Markeringsinterface

Det følgende bliver brugt en del i Javas standardbibliotek og er derfor værd at nævne (de defineres sjældent uden for standardbiblioteket).

Et markeringsinterface erklærer ingen metoder, men markerer et eller andet.
En klasse mærkes ved at implementere markeringsinterfacet.

Et markeringsinterface (eng.: marker interface) er et interface uden nogen metoder (eller variabler). Det tjener kun til at mærke klasser, sådan at deres objekter kan genkendes og behandles særskilt af et eller andet system.

Vigtigste eksempel fra standardbiblioteket på et markeringsinterface er Serializable, der tjener til at markere, om en klasse må serialiseres.

Et andet er Cloneable (der markerer, om det er lovligt at kopiere et objekt ved at kalde dets clone()-metode).

Et tredje er Remote i pakken java.rmi, der markerer, om et objekt er et 'fjernobjekt' i RMI (og dermed, om det skal forblive på serveren, og klienten skal have en fjernreference til det, eller det skal serialiseres, og indholdet transporteres over til klienten, som da får en kopi af objektet).

15.6 Ansvarsområder

En grundidé inden for objektorienteret design er, at hvert objekt skal have et eller flere ansvarsområder.

Ansvarsområder for et objekt kan være:

• At oprette nye objekter eller udføre en beregning

• At foretage en handling i andre objekter

• At kontrollere og koordinere aktiviteter i andre objekter

• At kende private data

• At kende relaterede objekter

• At kende ting, som objektet kan beregne

15.6.1 Eksempel på tildeling af ansvarsområder

Et eksempel på, hvordan man tildeler objekter ansvarsområder, er vist i neden for (fra bogen 'Objektorienteret programmering i Java', http://javabog.dk, kapitel 4):

public class Terning
{
  public int værdi;

  public Terning()
  {
    kast();
  }

  public void kast()
  {
    double tilfældigtTal = Math.random();
    værdi = (int) (tilfældigtTal * 6 + 1);
  }

  public String toString()
  {
    String svar = ""+værdi;
    return svar;
  }
}

Et terning-objekt har ansvaret for det, som vedrører den enkelte terning, dvs. ansvar for at vise den enkelte ternings værdi og at kaste den enkelte terning.

Et raflebæger-objekt har ansvar for alt det, som vedrører alle terningerne, dvs. oprettelsen af terningerne, kaste terningerne, kende summen af deres værdier og beskrive bægerets indhold.

Man kunne godt nøjes med én klasse og så have al koden i den, men en opdeling i forskellige klasser og dermed objekter med hvert sit ansvarsområde gør programmet lettere at overskue.

import java.util.*;

public class Raflebaeger
{
  public Vector terninger;            // Raflebaeger har en liste af terninger

  public Raflebaeger(int antalTerninger)
  {
    terninger = new Vector();
    for (int i=0;i<antalTerninger;i++)
    {
      Terning t;
      t = new Terning();
      tilføj(t);
    }
  }

  public void tilføj(Terning t)       // Læg en terning i bægeret
  {
    terninger.addElement(t);
  }

  public void ryst()                // Kast alle terningerne
  {
    for (int i=0;i<terninger.size();i++) 
    {
      Terning t;
      t = (Terning) terninger.elementAt(i);
      t.kast();
    }
  }

  public int sum()                      // Summen af alle terningers værdier
  {
    int resultat;
    resultat=0;
    for (int i=0;i<terninger.size();i++) 
    {
      Terning t;
      t = (Terning) terninger.elementAt(i);
      resultat = resultat + t.værdi;
    }
    return resultat;
  }
  
  public int antalDerViser(int værdi) // Antal terninger med en bestemt værdi
  {
    int resultat;
    resultat = 0;
    for (int i=0;i<terninger.size();i++) 
    {
      Terning t;
      t = (Terning) terninger.elementAt(i);
      if (t.værdi==værdi) 
      {
        resultat = resultat + 1;
      }
    }
    return resultat;
  }

  public String toString ()           // Beskriv bægerets indhold
  {
    // (vektorens toString() kalder toString() på hver terning)
    return terninger.toString();
  }
}

15.6.2 Ekspert

Hvilke ansvarsområder skal de enkelte klasser have?

Tildel den klasse, der har den nødvendige information til at udføre handlingen, ansvaret for handlingen.

I raflebæger-eksemplet har Terning-objekterne ansvar for de ting, der har med den enkelte terning at gøre, og Raflebægeret har ansvar for de ting, der vedrører alle terningerne, da bægeret kender terningerne.

15.6.3 Skaber

Hvem skal være ansvarlig for at oprette nye instanser (objekter) af en given klasse?

En klasse A skal være ansvarlig for at oprette nye instanser af en anden klasse B, hvis en eller flere af de følgende ting gælder:

• A indeholder objekter af typen B

• A består af objekter af typen B

• A kender de data, som B skal initialiseres med

• A bruger objekter af typen B meget

I raflebæger-eksemplet skal et objekt af typen Raflebaeger være ansvarlig for at oprette Terning-objekterne, da et raflebæger indeholder terninger, og raflebægeret bruger Terning-objekterne meget.

Kapitel 16, Skabende designmønstre, handler i øvrigt om oprettelse af objekter.

15.7 Lav kobling og høj kohæsion

Når man designer sit program, må man gøre sig klart, hvilke dele af programmet der vil være hyppige udvidelser og omstruktureringer i fremtiden.

Disse dele skal gerne være kendetegnet af lav kobling udadtil og høj kohæsion indadtil.

15.7.1 Lav kobling

Hvordan opnås det, at klasserne i et program bliver lette at udskifte, og eventuelt genbruge?

Koblingen (bindingen) mellem klasser er et mål for, hvor afhængige klasserne er af hinanden. Programmer med høj kobling er kendetegnet ved, at ændringer i en klasse har stor indflydelse på de øvrige dele af programmet, og at koden i den enkelte klasse er svær at forstå isoleret set.

Ved at sørge for, at klasserne har så lille afhængighed af hinanden som muligt, kan overskueligheden af programmet forøges, og det bliver lettere at udskifte dele af programmet.

Det er især vigtigt, hvis man overvejer at genbruge noget af programkoden i en anden sammenhæng, at man sørger for, at bindingerne mellem disse to dele er så lav som mulig.

Lav kobling giver ofte flere fordele ud over genanvendelighed:

• Fleksibilitet - den anvendte del kan lettere ændres eller udskiftes med noget andet.

• Overskuelighed - delene kan forstås uafhængigt af hinanden.

Måder at få lav kobling

• Lad klasser have referencer til så få andre klasser som muligt.

• Specificér vigtig funktionalitet i interfaces, og lad variabler (og parametre) være af interfacets type for at undgå at lægge dig fast på en bestemt implementation (dette er beskrevet i afsnit 15.3).

• Tildel den enkelte klasse et let forståeligt og ensartet ansvarsområde (høj kohæsion - se afsnit 15.7.2).

Høj kobling

Det modsatte, høj kobling, betyder, at programdelene er afhængige af hinanden, så man har et fastlåst program, hvor delene ikke kan isoleres fra helheden og anvendes i en anden sammenhæng.

Høj kobling opstår typisk, hvis ansvarsområderne ikke bliver ordentligt klarlagt. Et kendetegn på udflydende ansvarsområder er, at der er mange klasser involveret i at varetage en bestemt opgave (spaghetti-programmering). Koden vil ofte være svært forståelig, fordi man skal sætte sig ind i alle de forskellige klasser, som tager del i udførelsen af opgaven.

Høj kobling kan også opstå ved meget genbrug (arv er meget høj kobling) eller hvis man har mange små metoder, der kalder hinanden meget.

15.7.2 Høj kohæsion

Høj kohæsion (sammenhæng - eng.: high cohesion) vil sige, at et objekt har et overskueligt og let forståeligt ansvarsområde, eller eventuelt flere ansvarsområder, der er tæt relaterede til hinanden. Jo flere forskellige ansvarsområder et objekt/en klasse har, jo sværere bliver det at genbruge objektet/klassen.

15.7.3 Indkapsling

Den nemmeste måde at sikre lav kobling er ved at gøre metoder og variabler, man ikke ønsker brugt udefra, utilgængelige udefra.

Vi minder om at:

• Variabler og metoder erklæret public altid er tilgængelige inden for og uden for klassen.

• Variabler og metoder erklæret protected er tilgængelige for alle klasser inden for samme pakke. Klasser i andre pakker kan kun få adgang, hvis de er nedarvinger.

• Skriver man ingenting, er det kun klasser i samme pakke, der har adgang til variablen eller metoden.

• Hvis en variabel eller metode er erklæret private, kan den kun benyttes inden for samme klasse (og kan derfor ikke tilsidesættes i en nedarving). Det er det mest restriktive.

Adgangen kan sættes på skemaform: