F.I.R.S.T

Unit Tests sollten sich immer an folgende 5 Regeln halten:

Fast (Schnell)

Tests sollten schnell sein, den langsame Tests werden nicht oft ausgeführt. Dies führt dazu das Fehler spät oder gar nicht entdeckt werden. Beziehungsweise werden sie erst entdeckt wenn es nicht mehr so einfach ist sie zu beheben.

Independet (Unabhängig)

Tests sollten unabhängig voneinander und in beliebiger Reihenfolge durchgeführt werden können. Wenn Tests untereinander Abhängigkeiten haben, kann es dazu führen, das ein Fehler im vorigen Tests Auswirkungen auf den nächsten hat, dies erschwert eine Analyse.

Repeatable (Wiederholbar)

Tests sollten jederzeit wiederholbar sein und auf jeden System. Egal ob am Test oder am Produktionssystem. Ansonsten hat man immer einen Ausrede warum ein Test gerade failed.

Self-Validating (Selbstvalidierung)

Tests sollten ein Boolean Ergebnis liefern. Entweder wurde der Test bestanden oder eben nicht. Das lesen von Log Files und selbständiges kontrollieren des Ergebnisses ist zu vermeiden.

Timely (Rechtzeitig)

Tests sollten ummittelbar vor den Produktionscode geschrieben werden. Wenn die Tests erst danach geschrieben werden, kann dies dazu führen das bestimmte Passagen des Codes nicht oder nur sehr schwer testbar sind.

 

 

 

 

 

Unterschied Java EE und Java SE

Java SE

Standard Edition. This is the core Java programming platform. It contains all of the libraries and APIs that any Java programmer should learn (java.lang, java.io, java.math, java.net, java.util, etc…).

Java SE ist die Standard Edition. Es handelt sich hierbei um die Kernplattform von Java. Es beinhaltet alle Libraries und APIs die ein Java Entwickler kennen sollte wie java.lang, java.io, java.math ,java.net und java.util)

Java EE

Java EE ist die Enterprise Edition der Unterschied laut Wikipedia:

The Java platform (Enterprise Edition) differs from the Java Standard Edition Platform (Java SE) in that it adds libraries which provide functionality to deploy fault-tolerant, distributed, multi-tier Java software, based largely on modular components running on an application server.

In anderen Worten falls es sich um eine große Applikation die auf verteilten Systemen läuft sollte die Java EE verwendet werden. Diese setzt auf die JAVA SE auf und erweitet sie um eineige Funktionen. Wie zum Beispiel Database Access(JDBC, JPA, Remote Method Invocation (RMI), Messaging (JMS), Web Services und XML Processing. Es definiert auch die STandard APIs für Enterprise JavaBeans, SErvlets, Portlets und Java Server Pages.

Java EE arbeite grundsätzlich auf BAsis eines Applikation-Servers (z.B. JBoss). Für diesen werden spezielle Enterprise Java Beans (EJB) geschrieben. Diese sind auch nur auf den Applikationsserver lauffähig. Einer der Vorteile dabei ist, dass der Server für die Instanzerzeugung verantwortlich ist (Dependency Injection).

Einige Teile der EE waren so erfolgreich, das sie auch für SE zugänglich gemacht wurden, ein gutes Beispiel hierfür ist Hibernate.

 

Die Vier Säulen der Objektorientierung

Unter den 4 Säulen der Objektorientierung versteht man folgende Paradigmen:

Beziehungen

Objekte und Klassen existieren nicht für sich alleine, sondern stehen in Beziehungen zueinander

  • sie haben Gemeinsamkeiten (Generalisierung/Spezialisierung)
  • sie enhalten einander (Aggregation/Komposition)

Kapselung

Unter Kapselung versteht man den Schutz von Klassen und Variablen. Jedes Objekt ist von einer Kapsel umgeben und von außen sind nur die erwünschten Methoden und Variablen ersichtlich.

Vererbung

Eine Klasse kann auf eine Unterklasse vererbt werden. Die Unterklasse übernimmt die Eigenschaften der Elternklasse und kann diese erweitern oder auch einschränken. Ein Beispiel wäre die Elternklasse Fahrzeug mit der Unterklasse Auto. Jedes Auto ist ein Fahrzeug, aber nicht jedes Fahrzeug ein Auto.

Polymorphie

Dank Polymorphie ist es möglich, dass mehrere Unterklassen die selbe Botschaft verstehen aber unterschiedlich damit umgehen. So ist sowohl das Fahrrad sowie das Auto ein Fahrzeug und besitzen beide die Methode bremsen() auch sind die Resultate die selben, das Fahrzeug wird langsamer, jedoch können beide Methoden komplett unterschiedlich implementiert sein.

Model-View-Controller Pattern

Das Model-View-Controller Pattern wird öfters auch mit MVC abgekürzt. Jede Einheit hat klar definierte Aufgaben. Das Model enthält die Daten, die View stellt diese dar und der Controller vermittelt zwischen den beiden Einheiten.

Eingeführt wurde dieser Patterns bei grafischen Anwendungen für Desktop Applikationen. In den letzten Jahren ist es aber auch bei Web Applikation sehr populär geworden.

Ein bekanntes Beispiel für ein Web Framework welches mit MVC arbeitet ist CakePHP.

Ein einfaches Beispiel wäre ein Benutzerprofil. In einer Tabelle werden Name, E-Mail und Passwort eines Users gespeichert. Der User sieht auf einer Webseite seine Daten und kann diese auch bearbeiten. Diese Aufgabe übernimmt die View. Wenn der User seine Änderungen speichern will überprüft der Controller ob sich die Benutzerdaten geändert haben, falls ja übergibt er die Daten dem Model welche den Datenbankeintrag aktualisiert.

Drawing1

Der Vorteil liegt daran, dass die Dateien komplett unabhängig von ihrer Darstellung sind. Das Benutzerprofil könnte über eine Webseite oder über ein Mobile App bearbeitet werden, der Controller definiert die Schnittstelle und das Model bleibt unverändert.

In der Java Welt fällt es öfters schwer Controller und View voneinander zu trennen weil diese eng miteinander verbunden sind. Deswegen spricht man hier öfters von einen Delegate.

 

Observer Pattern

Die Definition dieses Patterns lautet:

„Definiere eine 1-zu-n-Abhängigkeit zwischen Objekten, so dass die Änderung des
Zustands eines Objekts dazu führt, dass alle abhängigen Objekte benachrichtigt
und automatisch aktualisiert werden.“

Stellen sie sich eine Party vor. Auf dieser Party gibt es 2 Gruppen von Gästen. Die einen die aktiv Erzählen und die anderen die passiv zuhören. Die Erzähler (Observable) interessiert es nicht wer ihnen zuhört, sie schweigen aber wenn sie gar keinen Zuhörer (Observer) haben. Die Zuhörer reagieren auf Witze der Unterhalter.

Realisierung

Um einen Erzähler zu realisieren bietet sich die Klasse Observable an. Diese verfügt über die beiden Methoden setChanged() und notifyObservers(). Mit setChanged() wird die Änderung angekündigt, und mit notifyObservers() wird sie tatsächlich übermittelt.

Würde es keine Änderungen geben, würde notifyObservers auch nichts übertragen.

Wir stellen jetzt unser Party-Szenario nach. Zuerst schreiben wir eine Klasse namens JokeTeller. Die erstellten Objekte erzählen einen Witz und verschicken sie an alle Zuhörer.

class JokeTeller extends Observable{
  private static final List() jokes = Arrays.asList(
    "Sorry, aber du siehst so aus, wie ich mich fühle.",
    "Eine Null kann ein bestehendes Problem verzehnfachen.",
    "Wer zuletzt lacht, hat es nicht eher begriffen.",
    "Wer zuletzt lacht, stirbt wenigstens fröhlich.",
    "Unsere Luft hat einen Vorteil: Man sieht, was man einatmet."
  );

  public void tellJoke(){
    setChanged();
    Collections.shuffle( jokes );
    notifyObservers( jokes.get(0) );
  }
}

setChanged() setzt intern eine Flag. Nach dem Aufruf der notifyObservers() Methode wird diese wieder gelöscht.

Interessierte Zuhörer (Beobachter) müssen sich am Observable-Objekt mit der Methode addObserver anmelden. Gültige Objekte sind aber nur jene, welche die Schnittstelle Observer implementieren. Mit der Methode deleteObserver(Observer) können sie sich wieder abmelden.

Die Namensgebung der Oberklasse ist leider etwas unglücklich gewählt. Normalerweise drückt „able“ immer ein Schnittstelle aus. In diesen Fall ist aber Observable eine echte Klasse während Observer eine Schnittstelle bezeichnet.

Die Observer Schnittstelle

Als nächstes folgt die Realisierung der Zuhörer Klasse. Die hat die Schnittstelle Observer implementiert. Ihre Aufgabe besteht darin auf die Witze des Erzählers zu reagieren. Als Attribute besitzt es nur einen Namen.

class JokeListener implements Observer{
  final private String name;

  JokeListener( String name ){
    this.name = name;
  }

  @Override public void update( Observable o, Object arg ){
    System.out.println( name + " lacht über: \"" + arg + "\"" );
  }
}

Die Party kann beginnen

Um unser Beispiel zu beenden erstellen wir jetzt eine Party Klasse und lassen unser Partygäste miteinander agieren.


public class Party
{
  public static void main( String[] args )
  {
    Observer achim    = new JokeListener( "Achim" );
    Observer michael  = new JokeListener( "Michael" );
    JokeTeller chris  = new JokeTeller();

    chris.addObserver( achim );

    chris.tellJoke();
    chris.tellJoke();

    chris.addObserver( michael );

    chris.tellJoke();

    chris.deleteObserver( achim );

    chris.tellJoke();
  }
}

Anwendung

Das Observer Pattern findet sich in fast allen Grafischen Oberflächen wieder. In der Java Welt werden sie als Listener bezeichnet. Besten Beispiel ist ein einfacher Button.

Von Natur aus ist nicht definiert was passieren soll wenn dieser gedrückt wird. Ein EventListener wird an den Button angehängt, der reagieren soll sobald ein bestimmtes Ereignis eintritt. In unseren einfachen Fall wenn der Button betätigt wird.

Zusammenfassung

  • Observer findet immer dann Anwendung, wenn sich der Status eines Objekts ändert und beliebig viele weitere Objeke darüber informiert werden
  • Es gibt Ereignisquellen und Beobachter
  • Beobachter müssen austauschbar sein