Undantag, Sammanfa,ning och Tentamensinfo. Objektorienterad programmering och design Alex Gerdes, 2018

Relevanta dokument
Undantag, Sammanfattning och Tentamensinfo. Objekt-orienterad programmering och design Alex Gerdes, 2016

Sammanfattning och Tentamensinfo Objekt-orienterad programmering och design (DIT953) Niklas Broberg, 2018

Objekt-orienterad Programmering och Design. TDA551 Alex Gerdes, HT-2016

Objekt-orienterad programmering och design. DIT953 Niklas Broberg, 2018

Objekt-orienterad Programmering och Design. TDA552 Alex Gerdes, HT-2018

Static vs Dynamic binding Polymorfism. Objekt-orienterad programmering och design (DIT953) Niklas Broberg, 2018

Design by Contract, Exceptions, Initialisering. Objekt-orienterad programmering och design (DIT952) Johannes Åman Pohjola, 2017

Static vs Dynamic binding Polymorfism. Objekt-orienterad programmering och design Alex Gerdes, 2016

Introduktion. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2017

Introduktion. Objekt-orienterad programmering och design (DIT953) Niklas Broberg, 2018

Classes och Interfaces, Objects och References, Initialization

Design by Contract, Exceptions. Objekt-orienterad programmering och design (DIT953) Johannes Åman Pohjola, 2018

Objektorienterad Programkonstruktion. Föreläsning 4 8 nov 2016

Generics och polymorfism. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016

Introduktion och OO. Objekt-orienterad Programmering och Design (TDA552) Alex Gerdes, HT-2018

Mutability och State. Objekt-orienterad programmering och design (DIT953) Niklas Broberg / Johannes Åman Pohjola, 2018

Objekt, klasser. Tillstånd Signatur Kommunikation Typ. Fält, parametrar och lokala variabler. Konstruktorer Metoder DAVA15

Design Patterns. Objekt-orienterad programmering och design Alex Gerdes, 2016

Principer, Pa+erns och Tekniker. Objekt-orienterad programmering och design Alex Gerdes, 2018

Generics och polymorfism. Objekt-orienterad programmering och design (DIT953) Niklas Broberg / Johannes Åman Pohjola, 2018

Dependencies High cohesion, low coupling. Objekt-orienterad programmering och design Alex Gerdes, 2018

Introduktion. Objekt-orienterad Programmering och Design (TDA551) Alex Gerdes, HT-2016

HT1 2013, FÖRELÄSNING 14 (INFÖR TENTAN)

Tentamen. 2D4135 vt 2005 Objektorienterad programmering, design och analys med Java Lördagen den 28 maj 2005 kl

Dependencies High cohesion, low coupling. Objekt-orienterad programmering och design (DIT953) Niklas Broberg, 2018

Principles of subclasses Objekt-orienterad programmering och design (DIT953) Niklas Broberg, 2018

Principer, Patterns och Tekniker. Objekt-orienterad programmering och design (DIT953) Niklas Broberg / Johannes Åman Pohjola, 2018

Principer, Patterns och Tekniker. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016

JUnit. Ska kompletteras med kodexempel på JUnit. DD2385 Programutvecklingsteknik Några bilder till föreläsning 12 21/5 2012

Principles of subclasses. Objekt-orienterad programmering och design Alex Gerdes, 2018

Föreläsning 8 - del 2: Objektorienterad programmering - avancerat

Generic type declarations. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016

Design Patterns. Objekt-orienterad programmering och design Alex Gerdes, 2018

Objektorienterad programmering i Java Undantag Sven-Olof Nyström Uppsala Universitet Skansholm: Kapitel 11

Lösningsförslag till omtentamen för TDA540 Objektorienterad Programmering

Arv. Fundamental objekt-orienterad teknik. arv i Java modifieraren protected Lägga till och modifiera metoder med hjälp av arv Klass hierarkier

Idag. Exempel, version 2. Exempel, version 3. Ett lite större exempel

Objektorienterad programmering i Java Undantag Sven-Olof Nyström Uppsala Universitet Skansholm: Kapitel 11

Classes och Interfaces, Objects och References Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016

Outline. Objektorienterad Programmering (TDDC77) En frukt har ett namn. Man kan lägga en frukt i en korg... Hashing. Undantag. Ahmed Rezine.

Objektorienterad Programmering (TDDC77)

Testning av program. Verklig modell för programutveckling

TDDE10 m.fl. Objektorienterad programmering i Java Föreläsning 6 Erik Nilsson, Institutionen för Datavetenskap, LiU

Subtyping, co- och contra-variance. Objekt-orienterad programmering och design Alex Gerdes, 2016

Klient/server. Översikt. Lektion 1: Webbtekniker från Microsoft. Webbteknik från Microsoft. Klient/server. Designmönster. Utrullning.

2I1049 Föreläsning 5. Objektorientering. Objektorientering. Klasserna ordnas i en hierarki som motsvarar deras inbördes ordning

Objektorienterad Programkonstruktion. Föreläsning jan 2016

Tentamen. DD2385 Programutvecklingsteknik vt 2013 Onsdagen den 22 maj 2013 kl Hjälpmedel: penna, suddgummi, linjal

Design Patterns Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2017

Subtyping, co- och contra-variance. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016 Johannes Åman Pohjola, 2017

TDDC30. Objektorienterad programmering i Java, datastrukturer och algoritmer. Föreläsning 4 Erik Nilsson, Institutionen för Datavetenskap, LiU

Objektorienterad programmering i Java, datastrukturer och algoritmer. Föreläsning 4 Jonas Lindgren, Institutionen för Datavetenskap, LiU

UML. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016

Lite om felhantering och Exceptions Mer om variabler och parametrar Fält (eng array) och klassen ArrayList.

TDDE10 m.fl. Objektorienterad programmering i Java Föreläsning 6 Erik Nilsson, Institutionen för Datavetenskap, LiU

Objektorienterad Programkonstruktion. Föreläsning 6 23 nov 2015

Separation of Concern. Objekt-orienterad programmering och design (DIT953) Niklas Broberg / Johannes Åman Pohjola, 2018

Klassen javax.swing.timer

TDDD78, TDDE30, 729A Typhierarkier del 2 Vad krävs? Hur fungerar det?

Modulär design Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016

Objektorienterad Programmering (TDDC77)

Modulär design. Objekt-orienterad programmering och design (DIT953) Niklas Broberg / Johannes Åman Pohjola, 2018

Instuderingsuppgifter läsvecka 2

SOLID är en akronym för fem stycken designprinciper som används vid mjukvaruutveckling. SOLID står för:

Föreläsning 12. Föreläsning 12. Rörliga figurer Klassen Timer Undantag Något om applets. Rörliga appletsfigurer Klassen Timer Undantag

Separation of Concern. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016 Johannes Åman Pohjola, 2017

OOP Objekt-orienterad programmering

Objektorienterad modellering och diskreta strukturer (EDAF10/EDA061)

Kopiering av objekt i Java

Föreläsnings 9 - Exceptions, I/O

DAT043 - Föreläsning 7

Föreläsning 8. Arv. Arv (forts) Arv och abstrakta klasser

Att skriva till och läsa från terminalfönstret

Designmönster/Design patterns

1 Comparator & Comparable

TDDC30. Objektorienterad programmering i Java, datastrukturer och algoritmer. Föreläsning 11 Jonas Lindgren, Institutionen för Datavetenskap, LiU

Static vs Dynamic binding Override vs Overload. Objekt-orienterad programmering och design Alex Gerdes och Sólrún Halla Einarsdóttir, 2018

Objektorienterad Programkonstruktion. Föreläsning 2 2 nov 2016

Lösningar till tentamen i EDAF25

Tentamen. DD2385 Programutvecklingsteknik vt 2015 Fredagen den 5 juni 2015 kl Hjälpmedel: penna, suddgummi, linjal

Lösningar till Fiktiv Tentamen på kursen. 2D4135 Objektorienterad programmering, design och analys med Java vt2004. Teoridel

Outline. Objektorienterad Programmering (TDDC77) Signatur. Klassen calculator. Överlagring (overloading) Arv (inheritance) Ahmed Rezine

Design Patterns. En kort introduktion

Grundläggande programmering, STS 1, VT Sven Sandberg. Föreläsning 14

Innehåll. dynamisk bindning. och programmering CRC) u Arv, polymorfi och

TENTAMEN. Kurs: Objektorienterad programmeringsmetodik 5DV133 Ansvarig lärare: Anders Broberg. VT-13 Datum: Tid: kl

Objektorienterad Programkonstruktion, DD1346. Tentamen , kl

Länkade strukturer, parametriserade typer och undantag

UML Objektdiagram. Objektorienterad modellering och design (EDAF25) Föreläsning 3. UML Sekvensdiagram. UML Objektdiagram. Agenda

Felhantering TDDD78, TDDE30, 729A

Objektorienterad programmering, allmänt

Viktiga egenskaper hos ett program (Meyer): Objektorienterad programmering, allmänt. Vilka egenskaper vill vi att våra program ska ha?

Imperativ programmering. Föreläsning 4

UML Objektdiagram. Objektorienterad modellering och design (EDAF25) Föreläsning 3. UML Sekvensdiagram. UML Objektdiagram. Agenda

Kursombud. Objektorienterad modellering och diskreta strukturer / design. Agile? Designprinciper EDAF10 EDA061. Lennart Andersson. Grupper för projekt

OOP Objekt-orienterad programmering

"Är en"-relation. "Har en"-relation. Arv. Seminarium 2 Relevanta uppgifter. I exemplet Boll från förra föreläsningen gällde

Lösningsförslag till tentamen i OOP, HI1027 Fredag 21 oktober 2011

Introduktion. Klasser. TDP004 Objektorienterad Programmering Fö 2 Objektorientering grunder

Tentamen Programmering fortsättningskurs DIT950

Transkript:

Undantag, Sammanfa,ning och Tentamensinfo Objektorienterad programmering och design Alex Gerdes, 2018

Saker går fel av många olika anledningar. Kass kod. Programmeraren har skrivit kod med buggar, som e.g. refererar :ll e; objekt som inte finns, indexerar utanför en array, dividerar med 0, etc. Felak:g användning av API. Programmeraren har inte läst dokumenta:onen, och uppfyller inte uppställda villkor, e.g. skickar e; nega:vt tal :ll en metod som bara hanterar posi:va tal. Externa faktorer som programmet inte har kontroll över, e.g. nätverket går ner, databasen kraschar, DVD:n är inte isa;, etc.

Felhantering Äldre programspråk (som C) har ingen strukturerad felhantering. Fel måste signaleras :ll användaren via värdet som returneras, så kallade felkoder. Leder :ll olika konven:oner, kra?igt ökad komplexitet, etc. Moderna impera:va programspråk (som Java) har strukturerad felhantering via excep+ons. DeFa innebär af vi slipper använda felkoder. Använd aldrig felkoder i Java. Aldrig. Många använder felkoder foriarande don t!

Excep&ons E" excep%on (undantag) i Java är e" objekt som representerar, och innehåller informa?on om, e" fel som uppstå" av en eller annan anledning. E" excep?on kan kastas (throw). E" excep?on kan fångas (catch). När e" excep?on inträffar innebär det en form av non-local transfer of control. Koden följer inte den normala strukturen, utan kan hoppa?ll e" catch-block långt bort från där excep?on kastas.

Error vs Excep+on Alla former av fel-objekt är i Java sub-klasser 6ll klassen Throwable, som namnet 6ll trots är en klass och inte e; interface. Throwable Error representerar e; fel som inte går a; återhämta sig från, exekveringen ska avslutas. E.g. VirtualMachineError Kan fångas, men bör bara fångas för a; avsluta programmet på e; snyggt sä;. Error Run3meExcep3on Exception

Checked vs Unchecked RuntimeException representerar buggar saker som inte borde inträffa och därför inte borde behöva varnas för. E.g. ArrayIndexOutOfBoundsException, IllegalArgumentException Dessa är unchecked, dvs behöver inte deklareras från metoder. Även Error och dess subklasser är unchecked. Alla andra exceptions är checked de representerar saker som vi förväntar oss kommer att inträffa under normal körning undantagsfall, förvisso, men ändå. Dessa måste vi varna användare för. E.g. FileNotFoundException, SQLException RuntimeException Unchecked excepdons Exception Checked exceptions

Checked excep*ons För checked exceptions måste vi deklarera, i metoders signaturer, om de kan komma att kasta exceptions av typen i fråga: public String readfile(string filename) throws FileNotFoundException { } En metod som anropar readfile måste antingen fånga FileNotFoundException, eller själv deklarera att den kan komma att kasta samma exception. Kallas exception propagation

A" fånga excep-ons public void appendfile(string filename, String str) throws IOException { try { String contents = readfile(filename); contents += str; writefile(filename, contents); } catch (FileNotFoundException e) { createfile(filename); writefile(filename, str); } } Vi fångar en sorts fel Men kan fortfarande orsaka andra sorters IOException, e.g. om vi inte har permission att skriva.

Ini$alisering av objekt

Ini$alisering av objekt När vi ber om att skapa ett nytt objekt med ett anrop till en konstruktor, sätter vi igång en kedja av händelser, som (förhoppningsvis, om inga exceptions händer) mynnar ut i att vi får tillbaka ett objekt av typen i fråga.

Initialisering av objekt 1. Sta&sk ini&alisering av klassen ( maskinen startar upp ). static ini&alizer blocks, samt ini&alisering för static a>ribut. Görs bara om maskinen inte redan startats av e> &digare anrop &ll konstruktor eller någon static metod (eller användning av static a>ribut). 2. Anrop &ll konstruktorn för objektets superklass ( maskinen utgår från &digare modell ) Explicit anrop &ll någon super( )-konstruktor måste göras allra först i en konstruktor. Om ingen super-konstruktor anropas explicit, anropas implicit super(). 3. Ini&alisering av objektet ( maskinen skapar grunden ) Non-sta&c ini&alizer blocks, samt ini&alisering för non-sta&c a>ribut. 4. Exekvering av konstruktorn självt ( maskinen färdigställer ) Koden som explicit skrivits i konstruktorn, förutom eventuellt anrop &ll en super-konstruktor.

Exempel på ini+alisering public class Init { static String hello = Hello! ; int x = 5; String foo; } Init() { constructorcode(); } Init init = new Init(); ======================== hello = Hello! ; super(); x = 5; foo = null; constructorcode(); E3 anrop av konstruktorn resulterar i 1. static init 2. super 3. object init 4. constructor

Default constructor Alla klasser har en default constructor som skapas oavsett om den skrivs ut eller inte: public MyClass(){} Den skapas bara om inga andra konstruktorer definieras. Så fort någon annan konstruktor definieras, oavsett signatur, så skapas ingen default constructor. Om en konstruktor i en sub-klass inte gör ett explicit anrop till någon super-konstruktor, då anropas implicit super(), vilket (om den inte omdefinierats) innebär default constructor. Felmeddelanden av typen There is no default constructor available in beror på att superklassen definierat en konstruktor med annan signatur, medan sub-klassen fortfarande försöker implicit anropa super(), som inte längre skapas implicit.

Sammanfa&ning

Quiz Vad är vårt mål? Svar: Att ni ska lära er att skriva objekt-orienterad kod, som är Lätt att underhålla (maintainable) Testbar Robust vid förändringar Återanvändbar (reuseable) Utökningsbar (extensible) Objekt-orienterad programmering och design

Småskalig programmering Triviala program Få klasser Några 100-tal rader kod En eller e9 fåtal programmerare Ingen eller kort livs<d Just do it

Storskalig programmering Mycket komplexa programsystem Flera miljoner rader kod 100-tals programmerare, geografiskt utspridda Lång livstid Software engineering Behov av verktyg Behov av processer Any code of your own that you haven't looked at for six or more months might as well have been written by someone else. - Eagleson's law

Objekt-orientering Objekt-orientering är en metodik för a2 rä2 använd! reducera komplexitet i mjukvarusystem. Rä2 använd ger objekt-orientering stora möjligheter Bll: Code reuse Extensibility Easier maintenance Fel använd riskerar objekt-orientering a2 skapa extra komplexitet Big ball of mud Det finns mycket dålig kod därute Det finns väldigt många missförstånd kring objekt-orientering.

Objekt-orienterad modellering Ett program är en modell av en (verklig eller artificiell) värld. I en objekt-orienterad modell består denna värld av en samling objekt som tillsammans löser den givna uppgiften. De enskilda objekten har specifika ansvarsområden. Varje objekt definierar sitt eget beteende. För att fullgöra sin uppgift kan ett objekt behöva support från andra objekt. Objekten samarbetar genom att kommunicera med varandra via meddelanden. Ett meddelande till ett objekt är en begäran att få en uppgift utförd. Alla dessa kriterier ska vara uppfyllda!

Design Designen (modellen) utgör underlaget för implementationen. Bra design minskar kraftigt tidsåtgången för implementationen. Brister i designen överförs till implementationen och blir mycket kostsamma att åtgärda. Vanligaste misstaget i utvecklingsprojekt är att inte lägga tillräckligt med tid på att ta fram en bra design. Bra design är svårt!! I allmänhet bör mer tid avsättas för design än för implementation.

Lärandemål

Blooms lärandepyramid DESIGNA, IMPLEMENTERA UTVÄRDERA ANALYSERA ANVÄNDA, APPLICERA REDOGÖRA KÄNNA IGEN Kod Verktyg och Principer

Lärandemål konkret Kunskap och förståelse: REDOGÖRA för objekt-orienterade design-principer. KÄNNA IGEN och REDOGÖRA för olika objekt-orienterade design-mönster, inklusiver deras sy?e och effekt. Färdigheter och förmåga: APPLICERA design-principer och design-mönster för ac åstadkomma sund objekt-orienterad design. ANVÄNDA och REDOGÖRA för grundläggande objekt-orienterade koncept, som klasser och objekt, primi/ver och referenser, metoder och konstruktorer, variabler och a6ribut, etc. ANVÄNDA och REDOGÖRA för mer avancerade språkmekanismer och tekniker, som excep/ons, generics, threads, defensive copying, etc. ANVÄNDA och REDOGÖRA för arv och parameteriserade typer, och därdll hörande mekanismer, för ac åstadkomma polymorfism och återanvändning av kod. DESIGNA och IMPLEMENTERA objekt-orienterade program för en given domän. UTFÖRA och BESKRIVA testning av objekt-orienterade program. Värderingsförmåga och förhållningssäc: ANALYSERA och UTVÄRDERA kod enligt principer för god objekt-orienterad design och implementadon.

Laboration: egen kod Sy#ar 'll a) ni ska få träna på a) använda tekniska aspekter, och få en känsla för polymorfism och code reuse Arv, delegering, generics(?), overriding,... Testar (främst) följande lärandemål: ANVÄNDA och REDOGÖRA för grundläggande objekt-orienterade koncept, som klasser och objekt, primi.ver och referenser, metoder och konstruktorer, variabler och a4ribut, etc. ANVÄNDA och REDOGÖRA för arv och parameteriserade typer, och där'll hörande mekanismer, för a) åstadkomma polymorfism och återanvändning av kod. UTFÖRA och BESKRIVA testning av objekt-orienterade program. (ANVÄNDA och REDOGÖRA för mer avancerade språkmekanismer och tekniker, som excep.ons, generics, trådar, defensive copying, etc.)

Labora&on: annans kod Sy#ar 'll a) ni ska träna på a) läsa och förstå existerande kod, a) anpassa egen och annans kod, och förbä)ra kod med hjälp av strukturerad refaktorering. Testar (främst) följandelärandemål: APPLICERA design-principer och design-mönster för a) åstadkomma sund objektorienterad design. ANVÄNDA och REDOGÖRA för mer avancerade språkmekanismer och tekniker, som excep%ons, generics, defensive copying, etc. ANALYSERA och UTVÄRDERA kod enligt principer för god objekt-orienterad design och implementa'on. DESIGNA och IMPLEMENTERA objekt-orienterade program för en given domän på e) sunt sä) med avseende på korrekthet, modifierbarhet och återanvändbarhet.

Inlämningsuppgift Inlämningen görs i samma grupper som 1digare. Testar (främst) följande lärandemål: ANALYSERA och UTVÄRDERA kod enligt principer för god objekt-orienterad design och implementa1on. KÄNNA IGEN och REDOGÖRA för olika objekt-orienterade design-mönster, inklusiver deras syde och effekt. APPLICERA design-principer och design-mönster för af åstadkomma sund objekt-orienterad design.

Muntlig tentamen Testar följande lärandemål: REDOGÖRA för objekt-orienterade design-principer. KÄNNA IGEN och REDOGÖRA för olika objekt-orienterade design-mönster; inklusive deras sy@e och effekt. REDOGÖRA för grundläggande objekt-orienterade koncept, som klasser och objekt, primi.ver och referenser, metoder och konstruktorer, variabler och a4ribut, etc. REDOGÖRA för mer avancerade språkmekanismer och tekniker, som excep.ons, generics, threads, defensive copying, etc. REDOGÖRA för arv och parameteriserade typer, och därcll hörande mekanismer, för ad åstadkomma polymorfism och återanvändning av kod.

Muntlig tentamen När: Under vecka 3, vid en 1dpunkt ni själva bokar på kurshemsidan Var: EDIT 5471, 6471 och (4/5/6)128 Vem: Dr. Alex Gerdes, Dr. Niklas Broberg, Dr. Jonas Almström Duregård Vad: se muntamanuset på kurshemsidan Hjälpmedel: Inga Tillhandahålles: UML syntax cheat sheet

Roadmap Delmoment 1. Tekniska verktyg och mekanismer 2. Principer 3. Pa:erns 4. Tekniker

Tekniska verktyg Klasser, objekt, gränssni2 (interfaces), typer, referenser (1-2) Sta=ska vs dynamiska typer, overriding och overloading (2-2) Arv vs delegering (3-1) Generics, varians (3-2, 4-1) Excep=ons (7-2) Trådar (7-1) Polymorfism (4-1) Encapsula=on (4-2)

Roadmap Delmoment 1. Tekniska verktyg och mekanismer 2. Principer 3. Pa:erns 4. Tekniker

Design-principer SOLID Single Responsibility Principle Open-Closed Principle Liskov Subs<tu<on Principle Interface Segrega<on Principle Dependency Inversion Principle Generella Composi<on over Inheritance (3-1) High Cohesion, Low Coupling (4-2) Separa<on of Concern (5-1) Command-Query Separa<on (5-1) Law of Demeter (7-1)

OPC: The Open-Closed Principle So1ware modules should be open for extension, but closed for modifica=on. (Bertrand Meyer) Förändring är det enda som är konstant. Utveckla framåt-kompatibelt förutsäg varförändring kommer behövas. Föreläsning 1-1

Dependency Inversion Principle Depend on abstractions, not on concrete implementations. Genom a( använda supertyper istället för subtyper kan vi minska beroendet av en specifik klass. Föreläsning 2-1, mer på 4-1

Single Responsibility Principle Föreläsning 4-2 A class should have only one reason to change. (Robert C. Mar8n)

ISP: Interface Segregation Principle No client should be forced to depend on methods it does not use. Om e% objekt A är stort, med mycket funk6onalitet, och objekt B beror på en liten del av denna funk6onalitet: Introducera en abstrak6on vars gränssni% är precis den del av A som B behöver bero på. Föreläsning 6-2

Liskov Subs+tu+on Principle If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is subsktuted for o2, then S is a subtype of T. (Barbara Liskov) S är en äkta subtyp till T endast om, för varje publik metod som finns i både S och T: S s metod godtar alla värden som T s metod godtar S gör alla beräkningar på denna indata som T gör (och kanske fler). Föreläsning 2-2

Roadmap Delmoment 1. Tekniska verktyg och mekanismer 2. Principer 3. Pa:erns 4. Tekniker

Vad är ett design pattern? E" design pa*ern (designmönster) är en (o2a namngiven) generell lösning av en vanligt återkommande situa9on inom (mjukvaru-)design. Termen och konceptet kommer ursprungligen ifrån arkitektur. Vi pratar mest om design pa"erns inom objekt-orienterad design, men de existerar (mer eller mindre u"alade och erkända) inom alla paradigmer. E" design pa"ern har ingen färdig kod de är abstrakta mallar för hur e" problem kan lösas. Formaliserade best-prac9ces. I en given situa9on och kontext kan vi instansiera e" design pa"ern med specifika klasser, metoder, etc, och få en färdig lösning.

Crea%onal Pa+erns Berör hur objekt skapas Factory Factory Method Singleton

Behavioral Patterns Berör hur objekt kommunicerar e.g. vilka metoder och signaturer vi använder Observer Template Method, Strategy, State Iterator Chain of Responsibility

Structural Pa*erns Berör hur vi strukturerar komponenter E.g. vilka klasser och interfaces vi bör använda, och hur de bör bero av varandra Adapter Bridge Composite Decorator Facade

Architectural Patterns Berör hur vi strukturerar våra program på en högre nivå än klasser Module Model-View-Controller

The Complete List (för tentan) Adapter, Bridge, Chain of Responsibility, Composite, Decorator, Facade, (Abstract) Factory, Factory Method, Iterator, Model- View-Controller, Module, Observer, Singleton, State, Strategy, Template Method

Roadmap Delmoment 1. Tekniska verktyg och mekanismer 2. Principer 3. Pa:erns 4. Tekniker

Tekniker Refactoring (1-1) Func2onal Decomposi2on (4-2) Immutability (6-1) Defensive Copying (6-1) Mutate-by-copy (6-1) Method Cascading (6-2)

Frågor?