Nutzen von Desgin Patterns?

[Nasenbaer]

Hi,
mittlerweile gibt es recht viele Bücher zu Desgin Patterns aber ich bin bisher nur ein einziges mal auf eines in einem Buch gestoßen, dass nicht speziell diese zum Thema hat.
Ich frag mich deshalb wie oft solche Design Patterns eigentlich genutzt werden. Denn es gibt nun wirklich unzählige Dinge, die einem das Programmiererleben leichter machen aber dennoch kaum genutzt werden. Sollte ich mir dazu mal ein Buch zulegen oder kann man auch gut drauf verzichten?

Mfg Michael

[Senior Sanchez]

Hi,
mittlerweile gibt es recht viele Bücher zu Desgin Patterns aber ich bin bisher nur ein einziges mal auf eines in einem Buch gestoßen, dass nicht speziell diese zum Thema hat.
Ich frag mich deshalb wie oft solche Design Patterns eigentlich genutzt werden. Denn es gibt nun wirklich unzählige Dinge, die einem das Programmiererleben leichter machen aber dennoch kaum genutzt werden. Sollte ich mir dazu mal ein Buch zulegen oder kann man auch gut drauf verzichten?

Mfg Michael

Hm, naja, ich habe kein Buch dazu, aber nutze schon nen paar Design Pattern. Zumindest speziell auf java geeicht gibts dazu auch lesbare Literatur im Web, aber das sollte natürlich auch auf andere Sprachen portierbar sein.

Ich selbst nutze hauptsächlich diese "Allerwelts"-Pattern: Singleton, Observer, MVC, Markerinterfaces und auf Arbeit manchmal noch das Visitor-Pattern.

[Nasenbaer]

In nem Buch wurde nämlich das Factory Pattern genutzt um die Anwendung OS und API unabhängig gestalten zu können und ich fand das schon genial.
Von der Singleton Sacher hatte ich auch schon gehört aber dass das ein Design Pattern ist wusst ich net. :)

Hast du en Link zu solchen Online Büchern? Programmiersprache ist mir egal - solange sie imperativ ist. :)

[Senior Sanchez]

In nem Buch wurde nämlich das Factory Pattern genutzt um die Anwendung OS und API unabhängig gestalten zu können und ich fand das schon genial.
Von der Singleton Sacher hatte ich auch schon gehört aber dass das ein Design Pattern ist wusst ich net. :)

Hast du en Link zu solchen Online Büchern? Programmiersprache ist mir egal - solange sie imperativ ist. :)

Stimmt, die Factory nutze ich auch sehr gerne.

Das wird zum Beispiel bei JDOM genutzt unter Java, wie mir gerade einfällt.

Das Buch hier, beschäftigt sich mit einigen pattern (auch wenns nicht das alleinige Hauptthema ist): http://www.galileocomputing.de/openbook/java2/

EDIT: Zum Thema Singleton.

Da habe ich mal vor einiger Zeit gelesen, dass das ansich nen ziemlich gehyptes Pattern ist. Sprich, wenn du viele Leute fragst, die sich mal damit beschäftigt haben, werden ziemlich viele das mit als erstes nennen ;) Es wurde dahingegend begründet, dass dies so sei, weil das Singleton-Pattern ja im Grunde wieder aufräumt mit der OOP und zur modularisierten Programmierung zurückkehrt, weil man sich eben Objekthandling bzw. das Handling mehrerer Objekte eines Typs gleichzeitig erspart.

Es ist schon recht praktisch, aber man muss eben aufpassen, dass man es nicht übertreibt und nur dort einsetzt wo es wirklich wichtig ist.
(Meiner einer nutzt das häufiger in Kombination mitm MVC-Pattern, da es meiner Ansicht nach nur eine gültige Model- und Controller-Instanz geben sollte, um einfach ne stärkere Kontrolle über den Programmfluss zu haben und einfach bestimmten Fehlern entgehen kann)

[Gast]

Hallo,

Design Patterns kannst du meines Wissens komplett vergessen.

[Gast]

jupp, das ist nur akademischer Quatsch, der in Managerohren gut klingt. Aber echte Softwareentwickler brauchen so einen Kram nicht. Die haben das im Blut.-

[Monger]

Normalerweise sollte man sein Wissen am aktuellen Problem ausrichten, und nicht umgekehrt.

Wenn man also an einem bestimmten Projekt dransitzt, würde ich mal empfehlen sich vorher ein bißchen umzuschauen, was andere schon vorher gehabt haben, was denen für Probleme über den Weg gelaufen sind, und welche Patterns sich da bewährt haben. Design Pattern heißt ja eigentlich nix anderes als: "Andere Leute haben mit diesem Lösungsweg gute Erfahrungen gemacht."

Beispiel: du willst eine Anwendung kreieren, mit der du Peer-To-Peer beliebige Daten übertragen kannst. Du willst außerdem Drittherstellern die Möglichkeit bieten, sich an deinen Client anzukoppeln.
Jetzt schaust du erstmal nach, was es denn für Probleme bei Software mit einer GUI geben könnte (wo man dann unweigerlich über MVC stolpert) was man denn tun könnte um seine Datenverbindung möglichst transparent zu gestalten (wo dann möglicherweise Begriffe wie SOAP auftauchen) und wie man überhaupt Peer to Peer umsetzen könnte (man muss das Rad ja nicht zweimal erfinden).

Es gibt natürlich ein paar Patterns und Standards die so wahnsinnig oft vorkommen, dass es nicht schaden kann sie schon vorher zu kennen. Aber gerade bei der Softwareentwicklung sollte man imho wirklich genau das lesen was einem auch weiterhilft, sonst verliert man nur unnötig viel Zeit, und wird schnell frustriert.

[Nasenbaer]

Normalerweise sollte man sein Wissen am aktuellen Problem ausrichten, und nicht umgekehrt.

Wenn man also an einem bestimmten Projekt dransitzt, würde ich mal empfehlen sich vorher ein bißchen umzuschauen, was andere schon vorher gehabt haben, was denen für Probleme über den Weg gelaufen sind, und welche Patterns sich da bewährt haben. Design Pattern heißt ja eigentlich nix anderes als: "Andere Leute haben mit diesem Lösungsweg gute Erfahrungen gemacht."

Beispiel: du willst eine Anwendung kreieren, mit der du Peer-To-Peer beliebige Daten übertragen kannst. Du willst außerdem Drittherstellern die Möglichkeit bieten, sich an deinen Client anzukoppeln.
Jetzt schaust du erstmal nach, was es denn für Probleme bei Software mit einer GUI geben könnte (wo man dann unweigerlich über MVC stolpert) was man denn tun könnte um seine Datenverbindung möglichst transparent zu gestalten (wo dann möglicherweise Begriffe wie SOAP auftauchen) und wie man überhaupt Peer to Peer umsetzen könnte (man muss das Rad ja nicht zweimal erfinden).

Es gibt natürlich ein paar Patterns und Standards die so wahnsinnig oft vorkommen, dass es nicht schaden kann sie schon vorher zu kennen. Aber gerade bei der Softwareentwicklung sollte man imho wirklich genau das lesen was einem auch weiterhilft, sonst verliert man nur unnötig viel Zeit, und wird schnell frustriert.
Eigentlich hast du vollkommen recht aber ob ich mir das nochmal ausgetrieben bekomme weiß ich net. Ich hab hier etliche Bücher stehen, die zwar nicht schlecht sind aber die zum Großteil nur angelesen wurden - ganz einfach weil ich die Erkenntnisse daraus einfach noch nicht brauchte. Bloß ich denk mir immer, dass ich alles gleich von Anfang an richtig machen will und deshalb kommt wohl auch immer nichts zustande. :/
Vielleicht sollte ich mich wirklich mal auf das wesentliche konzentrieren - nämlich ein Problem zu lösen mit der Software und nicht Software-Theorie lernen um nicht vorhandene Probleme zu lesen. :-)

[darph]

Hallo,

Design Patterns kannst du meines Wissens komplett vergessen.Naja, zum Glück läßt sich Wissen ständig erweitern. :ugly2:


Ich finde DPs eine feine Sache. Wie schon geschrieben, man muß das Rad ja nicht zweimal erfinden. Aber sie auf Deibel komm raus einzusetzen um des Einsetzens Willen - ja, das ist akademischer Quatsch (*an das Software-Engineering Praktikum erinner*).

[Trap]

Der klassische Link dazu:
http://norvig.com/design-patterns/

Design Patterns sind zu großen Teilen einfach "human compiler at work", man implementiert jedesmal neu von Hand Konzepte die formal genug beschrieben sind um die Implementierung der Konzepte zu automatisieren, nur fehlen in den üblichen Programmiersprachen die Abstraktionsmöglichkeiten um das als Nutzer der Programmiersprache nachträglich hinzuzufügen.

MVC ist eine der wenigen Ausnahmen bei denen man nicht fehlende Sprachfeatures implementiert, sondern ist einfach nur eine bewährte Struktur zur Entkopplung verschiedener Aspekte einer Anwendung mit Benutzerinteraktion.

[HajottV]

Ich frag mich deshalb wie oft solche Design Patterns eigentlich genutzt werden. Denn es gibt nun wirklich unzählige Dinge, die einem das Programmiererleben leichter machen aber dennoch kaum genutzt werden. Sollte ich mir dazu mal ein Buch zulegen oder kann man auch gut drauf verzichten?

Design Pattern dienen für mich als Horizonterweiterung, als ein Vorschlag, wie man gewisse Probleme angehen kann. Sie sind kein Allheitmittel für die Probleme, die bei der Erstellung großer Softwaresysteme entstehen - eigentlich gibt es da überhaupt kein Allheilmittel (außer gesundem Menschenverstand vielleicht).

Wer Design Pattern dogmatisch anwendet, landet mit ziemlicher Sicherheit in einer Sackgasse... das ist wie mit Kindern und Hämmern - auf einmal wird alls zum Nagel. Meine Erfahrung mit DP-Fetischisten ist, daß diese Leute in ALLEM ein Pattern (das "Bit-Singleton") sehen und am Ende riesige Klassenungetüme erschaffen, die so abstrakt und gewaltig sind, daß diese vor lauter Kraft gar nicht mehr gehen können.

Wer Design Pattern gar nicht kennt, dem fehlt vielleicht der Blick für gewisse sinnvolle Abstraktionen und mögliche Herangehensweisen an ein Problem. Man hat damit quasi einen Werkzeugkasten, aus dem man Werkzeuge für ein Problem heraussuchen kann... wobei man ein Pattern selten 1 zu 1 übernimmt. In der Regel sind die Probleme, die man hat, nicht direkt auf ein Pattern übertragbar, aber sie können dennoch als eine Orientierungshilfe dienen.

Gruß

Jörg

[Nasenbaer]

Jo dann werd ich die Dinger mal im Auge behalten und vielleicht mal Kurzbeschreibungen zu den üblichen Patterns raussuchen, dann weiß man wo man nachlesen muss wenn man das passende Problem vor sich hat. :)

[Senior Sanchez]

Jo dann werd ich die Dinger mal im Auge behalten und vielleicht mal Kurzbeschreibungen zu den üblichen Patterns raussuchen, dann weiß man wo man nachlesen muss wenn man das passende Problem vor sich hat. :)

Jau, aber nen paar sollte man kennen, denke ich. Wenns um GUI geht, gerade das MVC-Pattern (und in dem Zusammenhang vllt das Observer-Pattern) und ansonsten noch das Singleton und evt. die Factory.

[tokugawa]

jupp, das ist nur akademischer Quatsch, der in Managerohren gut klingt. Aber echte Softwareentwickler brauchen so einen Kram nicht. Die haben das im Blut.-

Hallo,

Design Patterns kannst du meines Wissens komplett vergessen.



Komplett falsch. Ihr solltet euch mal das originale Design Patterns-Buch von der Gang of Four (Gamma, Helm, Johnson, Vlissides) durchlesen.

Bei Design Patterns geht es auf keinen Fall darum, das Rad neu zu erfinden, die meisten Design Patterns sind altbekannte Dinge. Natürlich müssen Softwareentwickler die Patterns an sich im Blut haben - deswegen sind sie ja Softwareentwickler.

Aber den meisten Softwareentwicklern fehlt eine gemeinsame Vokabularbasis, und darum geht es bei Design Patterns.

Es geht nämlich hauptsächlich darum, den bekannten Dingen einen gemeinsamen bekannten Namen zuzuordnen, das Vokabular zu formalisieren, da es erst mit einem gemeinsamen Wortschatz möglich ist, zu kommunizieren (und Kommunikation ist in einem Mehr-Personen-Softwareprojekt ungemein wichtig).

Bevor also Gespräche wie dieses:

Softwareentwickler A: Bauen wir die Klasse A als so eine <beliebiges Wort A>
Softwareentwickler B: Häh? Nie gehört? Ich verwend immer <beliebiges Wort B>


Wo Wort A und B eigentlich dasselbe sind, aber beide Entwickler nicht dasselbe Vokabular besitzen.


Design Patterns kommen ursprünglich aus der Architektur, wo ebenfalls Architekturelemente einen Namen zugeordnet bekommen haben, damit Architekten bei der Planung miteinander kommunizieren können.

Design Patterns sind also keine revolutionäre neue Erfindung, sondern eine richtige Entwicklung, um Software-Designprozesse und Algorithmen/Datenstrukturen auf einen gemeinsamen Nenner zwischen Entwicklern zu bringen.

Man kann mit Design Patterns auch nicht angeben, in der Art "Kennst du das Singleton-Pattern? Ich schon, also bin ich besser als du!".

Kritisieren kann man an Design Patterns höchstens, dass manchmal neue Begriffe eingeführt werden für Dinge, bei denen eigentlich schon andere Namen etabliert sind.

[Nasenbaer]

Jo stimmt schon aber es ist doch ein Unterschied ob man die typischen Patterns beherrscht oder nicht. (Natürlich nur wichtig wenn man sie auch benötigt)

Denn auf diese Factory-Geschichte aus meinem Buch wäre ich ja nie selbst bekommen, sondern hätte eher die auch in dem Buch angesprochene schlechte Alternative umgesetzt - und zwar mit #ifdef usw. bestimmte Dateien halt includiert oder auch nicht - je nach System halt. Und das ist nun wirklich keine gute Sache aber ich dachte es ginge nicht anders.

[Gnafoo]

Full Ack @tokugawa

Das Buch kann ich nur empfehlen. Ist ein nettes Nachschlagewerk, dass die Patterns sehr ausführlich beschreibt und alle Nebeneffekte und Vor- und Nachteile gut darstellt. Außerdem zeigt es in der Einleitung auch sehr gut, wozu Design Patterns eigentlich gedacht sind.

Sicher, unbedingt brauchen tut man Design Patterns nicht immer, aber sie helfen einem doch, Dinge sauber umzusetzen. Es ist recht praktisch, wenn man sich da auskennt, um im Zweifelsfalle eine etablierte und durchdachte Lösung im Kopf zu haben (und sei es nur, dass man ein Stichwort zum Nachschlagen hat). Letztendlich sind die Patterns nichts anderes als gesammelte Erfahrungen von Softwareentwicklern, wie man gewisse Probleme möglichst geschickt lösen kann. Auf vieles davon würde man ohne weiteres nicht direkt kommen, von daher kann es auf jeden Fall nichts schaden, so etwas im Kopf zu haben (auch um darüber reden zu können, wie tokugawa schon sagte).