3 - J (mae)

Domain Model

Schichten

Pipes und Filter

Repositories (Blackboard)

Broker (Makler)

Model-View-Controll

Das Broker-Muster wird verwendet um die Zusammenarbeit in verteilten System zu koordinieren.

Ein Broker ist dabei verantwortlich für den Ablauf der Kommunikation verteilter Systeme sowie der technischen Übertragen von Anfragen, Ergebnissen und Ausnahmen.

Model: Enthält die fachlichen Bestandteile des Systems, den sogenannten Anwendungskern. Das Model kapselt alle fachlichen Daten und Dienste. Die Controller (s. u.) rufen diese Dienste nach Anforderung durch Anwender auf.

View: Zeigen Informationen (grafisch) für die Benutzer an

Controller: Nehmen Benutzereingaben oder -events an und leiten sie an passende Model- oder View-Bestandteile weiter.

Erzeugungs-Muster, Creational-Pattern

Struktur-Muster, Structural-Pattern

Verhaltens-Muster, Behavioral-Pattern

Das Singleton Entwurfsmuster sorgt dafür, dass es von einer Klasse nur eine einzige Instanz gibt und diese global zugänglich ist.

Dafür wird der Konstruktur privat deklariert. Nun kann einzig der Singletoncode selbst das Singleton instanziieren.

Weiterhin definiert die Singletonklasse eine global verfügbare Methode z.B. getInstance(), in der diese einzigartige Singletoninstanz zurückgegeben wird.

Biete eine Schnittstelle zum Erzeugen von Familien verwandter oder voneinander abhängiger Objekte, ohne ihre konkreten Klassen zu benennen

verschiedene methoden, z.B createTier, createPflanze, in interface definiert..

verschiedene klassen können interface implementieren... Tier = elefant, Pflanze = Palme 

Definiere eine Klassenschnittstelle mit Operationen zum Erzeugen eines Objekts, aber lasse Unterklassen entscheiden, von welcher Klasse das zu erzeugende Objekt ist.

Fabrikmethoden ermöglichen es einer Klasse, die Erzeugung von Objekten an Unterklassen zu delegieren.

Das Composite Entwurfsmuster ermöglicht es, eine verschachtelte (Baum)Struktur einheitlich zu behandeln, unabhängig davon, ob es sich um ein atomares Element oder um ein Behälter für weitere Elemente handelt. Der Client kann elegant mit der Struktur arbeiten.

Bietet eine einheitliche Schnittstelle (die "Fassade") anstatt einer Menge von Schnittstellen eines Subsystems. Die Fassadenklasse definiert eine "zentrale" Schnittstelle, welche die Benutzung des Subsystems vereinfacht.

Kontrolliere den Zugriff auf ein Objekt mit Hilfe eines vorgelagerten Stellvertreterobjekts.

Man verwendet einen Subjekt und einen Beobachter. Ein Subjekt kann eine beliebige Anzahl Beobachter "besitzen" (besser gesagt: Die Beobachter melden sich beim Subjekt an). Alle angemeldeten Beobachter werden (der Reihe nach!) benachrichtigt, wenn sich das Subjekt ändert. Als Reaktion auf diese Benachrichtigung synchronisiert sich jeder Beobachter mit dem Zustand des Subjekts. Das heisst jeder Beobachter frägt den (neuen) Zustand mit Hilfe von Anfragen an das Subjekt selber ab.

Einfachheit vor Allgemeinverwendbarkeit

Prinzip der minimalen Verwunderung (Erstaunliche Lösungen sind meist schwer verständlich)

Vermeiden Sie Wiederholung

Prinzip der einzelnen Verantwortlichkeit (Jede Klasse sollte eine strikt abgegrenzte Verantwortlichkeit besitzen)

Offen-Geschlossen-Prinzip (Software-Komponenten sollten offen für Erweiterungen, aber geschlossen für Änderungen sein)

Prinzip der gemeinsamen Wiederverwendung (Die Klassen innerhalb eines Pakets sollten gemeinsam wiederverwendet werden)

Keine zirkulären Abhängigkeiten

Prinzip der stabilen Abhängigkeiten (Führen Sie Abhängigkeiten möglichst in Richtung stabiler Bestandteile ein. Vermeiden Sie Abhängigkeiten von volatilen)

Liskov’sches Substitutionsprinzip (Unterklassen sollen anstelle ihrer Oberklassen einsetzbar sein, nichts überschreiben)

Prinzip der Umkehrung von Abhängigkeiten

Prinzip der Abtrennung von Schnittstellen

Prinzip solider Annahmen

Konvention vor Konfiguration

Wiederverwendbare Lösungen

Eine Anzahl Regeln, die beschreiben, wie bestimmte Aufgaben im Gebiet der Softwareentwicklung zu lösen sind

Beziehen sich auf ein oft auftretendes Design-Problem

Identifizieren und spezifizieren Abstraktionen die, von der Komplexität her, über den Klassen, Instanzen oder Komponeneten liegen

1. Der Name des Muster

2. Der Zweck des Musters: Das Problem, welches das Muster löst.

3. Wie man dieses Problem lösen kann

4. Die Einschränkungen und Bedingungen, die man beachten muss um das Problem zu lösen

Creational

Abstract Factory, Factory Method, Singleton

Structural:

Composite, Facade, Proxy

Behavioral:

Observer

SUT steht für »System Under Test«, manche Leute verwenden auch den Begriff CUT (»Class Under Test« oder »Code Under Test«). Wenn wir etwas testen, bezeichnen wir das, was wir testen, als das SUT.

Er sollte automatisiert und wiederholbar sein. 

Er sollte einfach zu implementieren sein. 

Einmal geschrieben, sollte er für die zukünftige Nutzung stehen bleiben. 

Jeder sollte in der Lage sein, den Test laufen zu lassen. 

Er sollte auf Knopfdruck ablaufen.

Er sollte schnell ablaufen.

=> Gute Tests können von jedem verwendet und ausgeführt werden

Integration Testing bedeutet, dass zwei oder mehr voneinander abhängige Softwaremodule als eine Gruppe getestet werden.

Ein Integration Test behandelt viele sich ergänzende Einheiten von Code, um zu untersuchen, ob die Software ein oder mehrere erwartete Resultate liefert, wohingegen ein Unit Test nur eine einzelne Einheit isoliert betrachtet.

Eine Regression ist ein Feature, das mal funktioniert hat, jetzt aber nicht mehr.

Ein Unit Test ist ein automatisiertes Stück Code, das eine zu testende Methode oder Klasse aufruft und dann einige Annahmen über das logische Verhalten dieser Methode oder Klasse prüft. Ein Unit Test wird fast immer mithilfe eines Unit Testing Frameworks erstellt. Er kann einfach geschrieben und schnell ausgeführt werden. Er ist vollständig automatisiert, vertrauenswürdig3, lesbar und wartbar.

Logischer Code ist jegliches Stück Code, das irgendeine Art von Logik enthält, so klein es auch sein mag. Es ist Logischer Code, wenn er irgendetwas von dem folgenden enthält: eine if-Anweisung, eine Schleife, eine switch- oder case- Anweisung, Berechnungen oder irgendeine andere Art von entscheidungsfindendem Code.

1. Schreiben Sie einen Test, der fehlschlägt, um zu zeigen, dass im Endprodukt ein Stück Code oder eine Funktionalität fehlt.  

2. Lassen Sie den Test erfolgreich ablaufen, indem Sie Produktionscode schreiben, der die Anforderungen des Tests erfüllt.

3. Überarbeiten Sie Ihren Code (Refactoring).

hochwertigen Code, hochwertige Tests und ein besseres Design für meinen Code zu entwickeln

Refactoring bedeutet die Änderung eines Code-Stücks, ohne die Funktionalität zu ändern. z.B Klasse umbenennen

Lösungsbeschreibung für eine gegebene Anforderung

(Wie die Lösung aufgebaut/konstruiert ist)

Anforderungen (einführung, randbedingungen) => scope!

Strukturen (verschiedene sichten)

übergreifende Themen (technische konzepte, entwurfsentscheidungen, szenarien)

packages

codestrukturen

schichten

namensräume

szenairen (use cases, abläufe)

unter verwendung der bausteine aus der bausteinsicht (wie spielt alles zusammen)

zu jedem usecase ein baustein und umgekehrt...