TDDC74 Programmering: Abstraktion och modellering

Project

Vt2 2009

Abstraktioner

Abstraktioner som ni säkert har koll på vid det här laget är viktigt i Scheme, och andra liknande språk.

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

• Ni slipper ändra på 1000 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 (tro mig, det är inte kul att spendera onödig tid på att felsöka ett parantesfel eller något annatenkelt), detta spar oftast oerhört mycket tid i sluttampen när koden börjar bli lång och saker ballar ur. Dvs det blir mycket lättare att isolera fel.
• Ni som siktar på högre betyg bör ha väl genomtänkta och uppdelade abstraktioner...

Abstraktioner kan delas upp i ett par kategorier beroende på funktion.

• Generella definitioner (General definitions)
Saker som t.ex (define game-board (make-gameboard)) och andra globala variabler.
• Selektorer (Selectors)
Car, cdr, vector-ref etc, procedurer som hämtar ut specifik information ur datatyper och objekt. exempelvis (ask pjäs 'type) är en typisk selektor. eller (cdr pjäs)...osv.
• Mutatorer (Mutators)
set-car!, set-cdr!, vector-set! osv. (ask pjäs set-type 'white) exempelvis. Dvs procedurer som ändrar i datatyper och objekt.
• Konstruktorer (Constructors)
Kopieringsprocedurer, procedurer som skapar nya datatyper, ex (make-board) och motsvarande. Cons hör hemma här.
• Komparatorer (Comparators)
Jämförande procedurer, eq?, list-equal?, equal?, =, långa (and (sak) (not annan_sak))-satser och saker. Detta är till stor hjälp när man skall reda ut långa cond-satser. Även (game-ended?), (place-empty? place), (valid-move? move) osv... Helt enkelt saker som returnerar bool-värden (#t och #f). Värt att tänka på är att cond och if behandlar alla värden utom *#f *som *#t, dvs (if 'ful_symbol 'true_värde 'false_värde) kommer returnera 'true_värde.
• Verktyg (Utilities)
Abstraktioner som inte passar in under ovanstående.

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 procedurer skall kommenteras med följande, dock behövs inte Beskrivning på små enkla procedurer där det är uppenbart vad som görs.

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

Exempel

En exempelfil från Sebastian Abrahamssons projekt.

Sidansvarig: Anders Märak Leffler
Senast uppdaterad: 2009-03-19