Forial Pursuit

[Coran]

Ich versuch mich auch mal an einer Antwort.

Also ganz klar ist, das es sich um einen Fachberiff aus der EVD handelt, genaugenommen aus der Software/Anwendungsentwicklung.

Nachdem ich jetzt ne halbe Stunde damit verbracht habe mich der Thematik etwas näher zu bringen versuch ich mal mit simplen Worten zu erklären.

Ein Factory-Pattern ist ein Programmbaustein der sozusagen den Status hat "funktioniert, kann man aus woanders gebrauchen". Dieser Baustein lässt sich nun in beliebigen anderen Programmen einbauen. Der Vorteil dieser Methode ist es, das diese Teile nicht immer wieder "neu" entwickelt werden müssen, sondern das sie so geschrieben sind das sie ebenso für andere Anwendungen nutzbar sind.

Mal schaun ob´s stimmt

[Thilo]

Also ganz klar ist, das es sich um einen Fachberiff aus der EVD handelt, genaugenommen aus der Software/Anwendungsentwicklung.

Das ist schon mal richtig - womit auch klar ist, dass die ganzen "Ich suche was in einer Fabrik" Antworten falsch sind.

Nachdem ich jetzt ne halbe Stunde damit verbracht habe mich der Thematik etwas näher zu bringen versuch ich mal mit simplen Worten zu erklären.

Bildungsauftrag erfuellt

Ein Factory-Pattern ist ein Programmbaustein der sozusagen den Status hat "funktioniert, kann man aus woanders gebrauchen". Dieser Baustein lässt sich nun in beliebigen anderen Programmen einbauen. Der Vorteil dieser Methode ist es, das diese Teile nicht immer wieder "neu" entwickelt werden müssen, sondern das sie so geschrieben sind das sie ebenso für andere Anwendungen nutzbar sind.

Diese Erklaerung ist allerdings nicht korrekt, bzw. da hast du was falsch verstanden. Aber es geht zumindest grob in die richtige Richtung

Damit es hier aber mal weitergeht, kommt hier von mir die Aufloesung:

Ein Factory Pattern ist ein ein sogenanntes Design Pattern. Design Patterns (im Deutschen auch Entwurfmuster genannt) sind festgelegte Methoden, mit denen häufig wiederkehrende Enwurfs-Probleme geloest werden koennen. Hauptsaechlich werden sie in der Informatik und da speziell in der Objektorientierten Programmierung verwendet. Es gibt ein sehr bekanntes Buch "Design Patterns - Elements of Reusable Object-Oriented Software", dass von 4 Typen geschrieben wurde, die den Spitznamen "Gang of Four" oder auch "GoF" bekommen haben. Wenn heute jemand im Bereich der Programmierung von einem "GoF Designpattern" spricht, meint er also eines der 23 Designpattern, die die vier in diesem Buch beschreiben haben. Das Factory-Pattern ist eines dieser "GoF Designpattern".

Vielleicht ist noch ein kleiner Exkurs in das Thema "Objektorientierte Programmierung" notwendig, damit man das versteht. Bei der herkömmlichen ("Prozeduralen") Programmierung arbeitet man mit Variablen, die irgendwelche Werte enthalten, und Funktionen, denen man meist irgendwelche Variablen übergibt, die dann innerhalb der Funktion irgendwas bewirken und ein Ergebnis zurueckgeben.  Daten und die Funktionen, die diese Daten verarbeiten, sind somit von einander getrennt. Wenn ich die Struktur meiner Daten aendere, muss ich auch die Funktionen aendern, die diese Daten verarbeiten. Das ist nicht sonderlich sinnvoll, wenn man z.B. Programmcode in verschiedenen Projekten verwenden  will.
Die Objektorientierte Programmierung geht einen Schritt weiter. Dort bilden Daten und die Funktionen, die diese Daten verarbeiten, ein in sich geschlossenes Objekt. Das restliche Programm kommuniziert nur über eine festgelegte Schnittstelle mit dem Objekt, welches dann seine eigenen Daten intern verwaltet. Dem Programmierer kann es egal sein, wie das Objekt intern arbeitet. Er muss nur wissen, wie die Schnittstelle aussieht. Fast alle aktuellen Programmiersprachen folgen dem objektorientierten Ansatz. Manche (wie z.B. Java) sind komplett Objektorientiert, andere (z.B. C++,  php) erlauben sowohl einen objektorientierten als auch einen prozedualen Ansatz.

Aber nun zurueck zum Factory Pattern. Wie schon gesagt, hat ein Objekt eine festgelegte Schnittstelle, über die man mit ihm kommuniziert. Wie es intern arbeitet, ist für das Programm erst mal egal (es ist also eine Art "Black Box"), so lange es seine Aufgabe erfüllt. Man kann nun in einem Programm verschiedene Objekte haben, die uber eine identische Schnittstelle verfuegen, aber unterschiedliche Aufgaben erledigen.

Ein ganz profanes Beispiel waere z.B. ein Objekt vom Typ  "Statusmeldung". Die festgelegte Schnittstelle ist, dass man dem Objekt eine Zeichenfolge übergibt. Nun gibt es im Programm zwei Objekte diesen Types, zum einen "StatusmeldungBildschirm" und zum anderen "StatusmeldungDatei". Der Unterschied ist, dass das erste Objekt die Meldung auf dem Bildschirm schreibt, und das zweite Objekt die Meldung stattdessen in eine Datei schreibt. Bei der herkoemmlichen prozedualen Programmierung muesste ich als Programmierer schon beim Schreiben des Programmes festlegen, welche Funktion ich aufrufe - die, die auf den Bildschirm schreibt, oder die, die in die Datei schreibt. Oder ich muesste zumindest in mein Programm komplexe Abfragen einbauen, die dann entscheiden, welche der beiden Funktionen aufgerufen werden soll. Und wenn ich mein Programm spaeter erweitern will, und noch die Moeglichkeit einbaue, die Meldung per eMail zu verschicken, dann muss ich tief in meinem Programmcode herumfrickeln. Ganz schlimm wird das, wenn man im Team an einem Programm arbeitet, und man daraufhin zu 5 verschiedenen Leuten rennen und sie bitten muss, an ihrem teil des Programms etwas zu aendern.

Bei der objektorientierten Programmierung verwendet man an der Stelle ein Objekt, das nach dem Factory Pattern aufgebaut ist, also ein sog. Factory-Objekt. Ich programmiere z.B. ein Factory-Objekt, dass mir Objekte vom Typ "Statusmeldung" liefert. Mein Programm "bestellt' in dem Moment, in dem es eine Statusmeldung ausgeben  will, bei diesem Factory-Objekt ein Objekt vom Typ "Statusmeldung". Das Factory-Objekt weiss (z.B. aus einer Konfigurationsdatei oder durch eine Benutzereingabe order irgendo anders her - wo genau braucht den Programmierer nicht zu interessieren), ob Statusmeldungen nun auf dem Monitor, in einer Datei oder sonstwo ausgegeben werden soll, und liefert mir daraufhin das richtige Objekt (also z.B. StatusmeldungDatei) zurueck. Mein Programm weiss nur, dass es nun Verbindung zu einem Objekt vom Typ Statusmeldung hat, und wie man mit diesem kommuniziert (d.h. wie die Schnittstelle aussieht). Es ruft also dieses Objekt auf, übergibt ihm den Text der Statusmeldung und das Objekt kuemmert sich darum, diese zu verarbeiten, in dem Fall also in eine Datei auszugeben. Wenn ich spaeter mein Programm erweitern will, und z.B. Statusmeldungen auch per eMail zu schicken, muss ich nur ein neues Objekt StatusmeldungEmail mit der fuer den Objekttyp "Statusmeldung" festgelegten Schnittstelle programmieren und dann das Factory-Objekt so aendern, dass es dieses neue Objekt kennt und weiss, wann es angewendet werden soll. Das eigentliche Programm muss ich nicht veraendern.

Das war jetzt ein sehr profanes Beispiel - und zudem auch eines, das man sicherlich auch mit prozedualer Programmierung halbwegs passabel loesen kann. Wenn es aber komplexer wird, kommt irgendwann das Pronzip der objektorientierten Programmierung so richtig zu Tragen. Heutzutage wird kaum noch eine komplexere Anwendung in prozedualer Weise programmiert.

ciao, Thilo (der hofft, ihr seid nun etwas schlauer und der Joost bittet, die naechste Frage zu stellen)

[Coran]

Danke Thilo, gut das ich das nicht alles schreiben mußte

Also meine Frage:

Bereich "keine Ahnung"

Warum dürften die Whiskey-Brauer der Marke ,,Jack Daniels"
eigentlich keine ruhige Minute haben?