Design Patterns

Design Patterns

Service

Architektur

Ein guter Überblick über das Konzept bzw. die Architektur des Service ist mit Hilfe der UML Diagrams möglich.

Strategy Pattern

Der Service verwendet das Strategy-Pattern an zwei Orten: Einerseits beim Auslesen der MenuStructureList mit Hilfe der konkreten Implementierung XmlMenuStructureLoader von IMenuStructureLoader, andereseits beim Cachen der Teletext Daten mittels der konkreten Implementierung SerializableSiteCache<TKey, TValue> von ISiteCache<TKey, TValue>.

Data Transfer Objects

Sämtliche Datenobjekte an den Client werden mittels DTOs realisiert. Die Data Transfer Objects besitzen das DataContract-Attribut. Die dazugehörigen Properties das Attribut DataMember.

Singleton

Weiterhin ist der ConfigurationHelper als Singelton realisiert.

HTML / JavaScript

Allgemein / Strategy Pattern

Der Einsatz von Design Patterns gestaltet sich in JavaScript oft schwierig, bedingt durch die Sprachspezifikation. Gerade das Fehlen von Interfaces erweist sich hier als grosser Nachteil. Oft hätten wir uns beispielsweise gewünscht, das Strategy-Pattern (http://en.wikipedia.org/wiki/Strategy_pattern) verwenden zu können, um dem OOP-Prinzip “Code against Interfaces” gerecht zu werden. Da das Strategy-Pattern allerdings des Vorhandenseins von Interfaces bedingt, mussten wir darauf verzichten. Wir haben aber versucht, den Code trotzdem möglichst unabhängig von der konkreten Implementierung einer Klasse zu schreiben.

Dependency Injection Pattern

Gleich am Startpunkt unserer App verwenden wir ein klassisches Dependency Injection Pattern (http://en.wikipedia.org/wiki/Dependency_injection).

Auszug aus index.html:

var client = new TeletextClient(SERVICE_URL);
var app = new TeletextApp(client);

Das “TeletextApp”-Objekt benötigt ein “TeletextClient”-Objekt, um mit dem Webservice kommunizieren zu können. Diese Abhängigkeit soll das “TeletextApp”-Objekt jedoch nicht selber erstellen, sondern sie soll von aussen eingefüllt werden – dies führt zu einer besseren Aufteilung der Verantwortung, da das “TeletextApp”-Objekt zu keinem Zeitpunkt die Service-URL kennt (was gut ist, denn das “TeletextApp”-Objekt kommuniziert nur über das “TeletextClient”-Objekt mit dem Service). Die beiden Objekte (Client und App) sind dadurch lose gekoppelt.

Composite Pattern

Bei genauerem Hinschauen kann auch im HTML-Code ein Design Pattern gefunden werden. Die Verschachtelung der einzelnen Elemente ist nämlich ein Composite Pattern (http://en.wikipedia.org/wiki/Composite_pattern).

Auszug aus index.html:

<div data-role="page">
     <div data-role="header" class="header">
        <h1>CrossText: Page <span id="pageNumber">100</span></h1> 
     </div>
      <div data-role="content" class="content" style="padding: 0;"></div>
</div>

Das “page”-Element beinhaltet ein “header”- und ein “content”-Element. Das “header”-Element beinhaltet ein “h1”-Element, welches Text und ein “span”-Element beinhaltet. Dieser Struktur können beliebig Elemente hinzugefügt oder entfernt werden.

Observer Pattern

Durch die Verwendung des EventSystems wird auch ein Observer Pattern (http://en.wikipedia.org/wiki/Observer_pattern) eingesetzt.

Auszug aus TeletextApp.js:

$("#MenuStructure").click(function()
{
     app.GetMenuStructure();
});

Beim DOM-Element mit der ID “MenuStructure” wird ein “click”-Event mit der Callback-Methode “GetMenuStructure” des “TeletextApp”-Objekts registriert. Das “TeletextApp”-Objekt überwacht also das “MenuStructure”-Element.