-
ACHTUNG - NEUES BLOG
Ab sofort steht unter http://devtyr.norberteder.com mein neues Blog zur Verfügung. Dieses Blog wird nicht weiter betreut, bleibt aber erhalten. Neue Eintr%auml;ge erfolgen nur mehr im neuen Blog. Kommentare werden ebenfalls nicht mehr behandelt. Wer weiterhin meinen Einträgen und Aktivitäten folgen möchte, möge bitte RSS-Feeds, Verlinkungen etc. an die neue Location anpassen.
|
Writing Software Patterns
21.09.06 - Patterns Beitrag von Norbert EderDesign Patterns: Die Geschichte
28.03.06 - Patterns Beitrag von Norbert Eder| | Unter Was sind Design Patterns wurde der Begriff Design Pattern bereits definiert und auch die unterschiedlichen Arten wurden angeführt.
In diesem Beitrag wird auf die Geschichte der Design Patterns eingegangen.
Bereits in den 1970er Jahren wurde die erste Sammlung von Entwurfsmustern erstellt - allerdings von einem Architekten namens Christopher Alexander. Die Idee dahinter hat sich seitdem nicht verändert. Nur fand seine Sammlung wenig Anklang unter anderen Architekten, in der Softwareentwicklung wurde die Idee jedoch bald darauf aufgegriffen und erfreut sich großer Beliebtheit. Ende der 1980er wurde die Sammlung von Chritopher Alexander von Kent Beck und Ward Cunningham aufgegriffen und entwickelten auf deren Basis Entwurfsmuster für grafische Benutzerschnittstellen.
Eine neue Ära begann dann mit Erich Gamma. Nach seiner Promotion an der Universität Zürich, 1991, ging er in die USA und verfasste zusammen mit Richard Helm, Ralph Johnson und John Vlissides das Buch Design Patterns - Elements of Reusable Object-Oriented Software. In diesem Buch wurden 23 Design Patterns beschrieben. Dies verhalf den Entwurfsmustern zum Durchbruch. Die vier Autoren sind gemeinhin auch unter Gang of Four (GoF) bekannt.
Zur Übersichtlichkeit verwendete die GoF ein einheitliches Schema um die Design Patterns zu beschreiben. Nachfolgend eine kurze Übersicht:
- Mustername und Klassifikation
- Zweck
- Synonyme
- Motivation
- Anwendbarkeit
- Struktur
- Beteiligte Klassen (Akteure)
- Zusammenspiel der involvierten Klassen
- Vor- und Nachteile
- Implementierung
- Beispielcode
- Praxiseinsatz
- Querverweise
Anhand dieses Schemas konnte ausreichend Information zum entsprechenden Design Pattern geliefert werden (Wann ist es einsetzbar, etc.).
| | | Kommentar hinzufügen
| 1 Trackbacks
| Permalink | Trackback-URL |
Patterns: Command Pattern
21.03.06 - Patterns Beitrag von Norbert Eder| | Das nächste Pattern, welches ich in meiner Rubrik Patterns vorstellen möchte, ist das Command-Pattern.
Defintion
Das Command Pattern ermöglicht die Repräsentation von Aktivitäten in eigenständigen Objekten.
Was bedeutet dies in der Praxis?
Innerhalb der selben Struktur können unterschiedliche Commands ausgeführt werden, die jeweils eine bestimmte Aufgabe besitzen. Unabhängig davon, welche Aufgabe ein Command hat, muss das ausführende Konstrukt nicht verändert werden. Zusätzlich besteht die Möglichkeit, Commands in beispielsweise einer Queue abzulegen um hintereinander abgearbeitet zu werden.
Beispiel-Implementierung
Der Aufbau des Command Patterns wird zwar in manchen Fällen recht aufwändig und kompliziert dargestellt, gestaltet sich in der Praxis jedoch als sehr einfach. Es wird ein Interface ICommand erstellt welches die notwendige Methode Execute() zur Verfügung stellt. Jeder konkrete Command implementiert dieses Interface und die Methode Execute() wird dabei mit der Logik des Commands befüllt. In einigen Fällen macht es auch durchaus Sinn, einen abstrakten Command einzufügen, der bereits Basisfunktionalitäten zur Verfügung stellt.
public interface ICommand
{
string Message{get;set;}
void Execute();
}
Dieses Interface schreibt also die Methode Execute() vor, die von jedem Command implementiert werden muss. Weiters wird eine Eigenschaft Message vorgeschrieben, die eine entsprechende Nachricht speichern soll. Konkreter Anwendungsfall wäre eine Fehlermeldung wenn der Command auf einem entfernten Host ausgeführt wird (kann als eine Ergänzung zu einem State gute Dienste leisten).
In diesem Beispiel wird nun ein abstrakter Command erstellt, der die Eigenschaft als Basisfunktionalität zur Verfügung stellt:
public abstract class Command : ICommand
{
private string message = null;
public string Message
{
get { return this.message; }
set { this.message = value; }
}
public abstract void Execute();
}
Alle Commands, die nun vom abstrakten Command ableiten, müssen die Eigenschaft Message nicht mehr implementieren, da diese bei der Ableitung übernommen wird. Lediglich die Methode Execute ist zu überschreiben. Dies wird anhand des folgenden Sourcecodes gezeigt:
public class ConcreteCommand : Command
{
#region ICommand Members
public override void Execute()
{
this.Message = "This is a concrete command implementation.";
}
#endregion
}
Hier passiert nichts anderes, als dass die Eigenschaft Message mit einem String befüllt wird.
Weiters wird von mir noch eine Klasse Executor benutzt, der für die Ausführung der Commands zuständig ist.
public class Executor
{
public void ExecuteCommand(ICommand ic)
{
ic.Execute();
}
}
Wie hier zu sehen ist, wird ein ICommand übergeben, der anschließend ausgeführt wird. Dadurch kann jeder beliebige Command ausgeführt werden und eine Erweiterung ist nur dann notwendig, wenn der Executor selbst diverse neue Features bekommt.
Zusammenfassung
Da im Falle des Command Patterns nur mehr die einzelnen Commands implementiert werden müssen, das ausführende Framework sich jedoch nicht ändert, eignet sich dieses Pattern sehr gut für eine Client-Server Kommunikation und wird daher auch oft eingesetzt, wenn Clients beispielsweise mit WebServices interagieren.
Nachfolgend findet sich ein kleines Testprogramm, welches den gesamten Ablauf dieses Patterns zeigt.
Beispiel-Anwendung: Download
| | | 6 Kommentare
- 2699 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Singleton Pattern
07.01.06 - Patterns Beitrag von Norbert Eder| | Das Singleton-Pattern ist wohl eines der bekanntesten Design-Pattern überhaupt. Ziel ist es, dass es innerhalb einer Anwendung von einer Klasse nur ein Objekt gibt. Daher kann global auf dieses Objekt zugegriffen werden.
Einsatzgebiete für das Singleton-Pattern finden sich einige:
- Logging-System welches Logging-Daten in eine Datei schreibt
- Druckerqueue in der alle Dokumente der Reihe nach abgearbeitet werden sollen
- Implementierung eines globalen Storages
- etc.
Das Singleton-Pattern gehört zu den Erzeugungsmustern (engl. Creational Patterns).
Im nachfolgenden Sourcecode-Beispiel wird ein thread-sicherer Singleton abgebildet. Thread-sicher bedeutet, immer nur ein Thread auf eine Ressource zugreifen kann. Dadurch können ungewollte Effekte vermieden werden.
public class Singleton
{
private static Singleton instance = null;
private static object lockObject = new object();
private Singleton()
{
}
public static Singleton GetInstance()
{
lock (lockObject)
{
if (instance == null)
instance = new Singleton();
}
return instance;
}
}
Zu beachten ist, dass ein Singleton einen privaten Konstruktor hat. Dadurch wird gewährleistet, dass ausserhalb der Klasse kein Objekt der Singleton-Klasse erstellt werden kann. Dafür wird die Methode GetInstance() verwendet. Hier findet die Überprüfung statt, ob es bereits eine Instanz gibt. Wenn nicht, wird eine neue erstellt, ansonsten wird die bestehende Instanz zurückgegeben. Prinzipiell kann die Methode GetInstance() auch als Getter-Property abgebildet werden.
Die Thread-Sicherheit bringt uns in diesem Fall das Schlüsselwort lock. Diesem kann als Parameter ein Objekt - welches gesperrt werden soll - übergeben werden. Solange das übergebene Objekt durch einen Lock gesperrt wird, kann kein anderer Thread darauf zugreifen.
Weitere Informationen zu diesem Thema sind unter anderem im Weblog von Dirk Primbs zu finden.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
Was sind Design Patterns?
04.01.06 - Patterns Beitrag von Norbert Eder| | Bevor unterschiedlichste Design-Patterns erklärt werden, muss definiert werden, worum es sich bei Design-Patterns handelt.
Hier eine kurze Definition:
"Jedes Muster beschreibt in unserer Umwelt ein beständig wiederkehrendes Problem und erläutert den Kern der Lösung für dieses Problem, so dass diese Lösung beliebig oft angewendet werden kann, ohne sie jemals ein zweites Mal gleich auszuführen"
A Pattern Language von Christopher Alexander, Oxford
University Press 1977.
Was genau bedeutet dies? Jedes Pattern wird/wurde für eine bestimmte Aufgabe entwickelt und kann darin generisch eingesetzt werden. Sie sollen also häufig gestellte Aufgaben vereinfachen. Weiters handelt es sich um eine Beschreibung der zusammen arbeitenden Objekte und Klassen.
Zur weiterführenden Recherche möchte ich erwähnen, dass es unterschiedliche Typen von Design-Patterns gibt:
- Erzeugungs-Pattern
- Struktur-Pattern
- Verhaltens-Pattern
Sollten nähere Erklärungen von Nöten sein, werde ich dies an den entsprechenden Stellen nachholen, oder zu den unterschiedlichen Typen noch entsprechende Einträge schreiben.
| | | Kommentar hinzufügen
| 1 Trackbacks
| Permalink | Trackback-URL |
Design-Patterns kurz und bündig
01.01.06 - Patterns Beitrag von Norbert Eder| | Ab sofort gibt es eine neue Kategorie Patterns. Darin werde ich alle möglichen Design Patterns anhand eines kurzen Beispiels erklären und auch entsprechende Hintergründe liefern.
Wünsche, Vorschläge werden natürlich gerne angenommen!
| | | 3 Kommentare
- 895 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Zurück
|
|
|
|
|
|
|
