Göm menyn

TDDC74 Programmering: Abstraktion och modellering

Project

Abstraktioner

Att definiera ett lager av abstrakta datatyper (eller beskriva en tydlig uppsättning objekt med tydliga ansvarsområden) är - som ni vet vid det här laget - rätt viktigt. Att göra en tydlig proceduriell abstraktion, med en uppdelning av beräkningar i funktioner med tydliga ansvarsområden, är det också.

Detta gör livet lättare av ett par anledningar

  • Ni slipper ändra på många ställen i er kod om ni vill ändra något i en funktion eller en datatyp.
  • Koden blir lättare att läsa, procedurnamn som är förklarande gör livet mycket lättare för både er och andra.
  • Koden blir MYCKET lättare att felsöka.

    Låt exempelvis säga att man märker att fel uppstår när man försöker placera en pjäs på en viss upptagen plats på brädet. Detta kan uppstå på grund av fel i inmatningen, i spelmekaniken, eller någon annan stans. Då är det en fördel om koden innehåller rader som ((place-free? row col board) ...) snarare än långa oläsliga uttryck med car och cdr. Dessutom riskerar car-cdr-kedjan i sig att vara en felkälla, om man ändrat något någon annan stans i koden.

  • Ni som siktar på högre betyg måste dessutom ha väl genomtänkta och uppdelade abstraktioner. Ni som siktar på att, i arbetslivet eller på fritiden, kunna arbeta i projekt med fler än två deltagare måste lära er att bygga eller använda interface som gör att er kod kan användas av någon som inte har full koll på alla detaljer i implementationen. Det finns ingen som har koll på alla implementationsdetaljer i Linux-kärnan, eller JAS Gripen.

Objektstruktur

Om ni gör ett objektorienterat projekt, finns det ett antal små råd som bör tänkas på:

  • Svarar varje objekt mot något vettigt, antingen i världen eller i er tänkta programvärld?
  • Har objekten tydliga ansvarsområden, eller finns det några saker som bara fungerar som ''databehållare'' som andra objekt av olika slag använder? Fundera igenom designen isåfall.
  • Har ni tydliga sätt att kommunicera med alla objekt? Bygger er design på att objekt kan göra ''otillåtna'' ändringar på andra ställen, för att ''ni vet hur det fungerar'' (modell att ha ett säkert sätt att flytta pjäser på ett spelbräde, men ibland väljer att inte använda det)? Tänk isåfall igenom det ett varv till.
  • Relaterat: är rätt metoder publika?
  • Har ni tänkt igenom klasstrukturen? Lägg inte all funktionalitet i en viss klass om det inte behövs, utan använd arvsmöjligheterna. Skriver ni ett spel med t ex bilar och stridsvagnar, där båda ska kunna flytta på sig - skapa en riktig arvsstruktur (mer om detta finns i OOP-kompendiet)!.

Kommentering

Först i varje kod-fil skall det finnas ett s.k kodhuvud där ni berättar följande:

  • Syfte med filen
  • Vilka/vem som skrivit den
  • Senaste ändring och datum.

Alla större procedurer skall kommenteras med följande:

  • Beskrivning, vad proceduren gör
  • Indatatyper
  • Utdatatyper

För mindre procedurer där det är uppenbart vad de gör, behövs inte detta.

Exempel: add-to-db: flight x databas -> databas (indata är en flight och en databas, utdata är en databas).

Som tumregel: skriv inte kommentarer inuti definitioner. Om ni gör det, skriv kommentar på egen rad, och beskriv exv en grupp av fall (modell ;; Databasen behöver uppdateras).

Det ska gå att läsa annat ur koden. För att hårdra det lite: man ska skriva (if (place-taken? row col board) ...), snarare än ett uttryck i stil med (if (assq (cons x y) b) ...) följt av den förklarande kommentaren ";; om platsen är upptagen så ska vi inte göra något, annars så måste vi consa på den och...".


Sidansvarig: Anders Märak Leffler
Senast uppdaterad: 2015-03-10