Entwurfsmuster: Mehr als nur ein Elfenbeinturm?
-
Weil es vor dem Hype wohl "bekannte Problemlösungen" hieß. Weil das aber schlecht klingt, hat man sich den Begriff Design Pattern einfallen lassen. Die Problemlösungen selbst haben dann natürlich auch noch einen Namen gebraucht...
Und Design Pattern haben ja viel mit Softwarearchitektur zu tun, dürfte man ja als Untermenge sehen. Dann ist auch nichts falsches an meiner Aussage.
-
Shade Of Mine schrieb:
SingletonFactoryObserver schrieb:
Design Pattern sind keine Namen, sondern die Problemlösungen selbst. Namen für Design Pattern sind nur Namen für Design Pattern. Diese Problemlösungen sind nun sehr durchdacht und verkörpern Eigenschaften, die gut designte Software aufweisen sollte. Wenn ich Design Pattern kenne, weiß ich auch, warum das jeweilige Pattern die Softwarequalität steigern kann (und welche Nachteile es hat).
IMHO kann man in deinen Aussagen einfach Design Pattern durch "beschäftigen mit Software Architektur" ersetzen und es würde passen.
"beschäftigen mit Software Architektur" sind keine Namen, sondern die Problemlösungen selbst. Namen für "beschäftigen mit Software Architektur" sind nur Namen für "beschäftigen mit Software Architektur". Diese Problemlösungen sind nun sehr durchdacht und verkörpern Eigenschaften, die gut designte Software aufweisen sollte. Wenn ich "beschäftigen mit Software Architektur" kenne, weiß ich auch, warum das jeweilige Pattern die Softwarequalität steigern kann (und welche Nachteile es hat).
Also auf mich wirkts komisch.
-
Jester schrieb:
Also auf mich wirkts komisch.
uU wirkt es besser wenn man nur den einen satz nimmt?
Nach einer intensiven Auseinandersetzung mit "Software Architektur" bin ich mir also über gute Softwareeigenschaften bewusst, welche in bestimmten "Software Architekturen" besonders zum Tragen kommen. Gleichzeitig weiß ich natürlich auch über etwaige `pitfalls' bescheid.
-
Finde ich wenig überzeugend. Ich muß mich aber auch ein bißchen über Deine Argumentationsweise wundern. Du verstehst "kennen" als "auswendig lernen" und ähnliche Dinge. Stellst Du Dich da grad absichtlich ein bissel an? Wenn ja, wieso verwendest Du dann selbst offensichtliche Ungenauigkeiten wie "Design Patterns sind Namen"?
-
Jester schrieb:
Finde ich wenig überzeugend. Ich muß mich aber auch ein bißchen über Deine Argumentationsweise wundern. Du verstehst "kennen" als "auswendig lernen" und ähnliche Dinge. Stellst Du Dich da grad absichtlich ein bissel an? Wenn ja, wieso verwendest Du dann selbst offensichtliche Ungenauigkeiten wie "Design Patterns sind Namen"?
Vielleicht ist es so klarer:
bringt es dich mathematisch weiter ein formelheft auswendig zu lernen?
Nein.Design Pattern sind in etwa Formelnamen. Sie ermöglichen es über Berechnungen zu sprechen. Aber auch wenn ich nicht die Formelnamen kenne, so kann ich dennoch ohne Probleme alle Berechnungen ausführen. Ich muss ja nicht wissen wie das heisst was ich mache, solange ich es verstehe.
Design Pattern sind nun genau diese Formel Namen. Früher hat man gesagt "die formel die was wo ich bei einem rechtwinkeligen dreieck die fehlende seite ausrechnen kann wenn ich 2 seiten gegeben habe" und man hat es ausgerechnet. dann hat jemand die formel aufgeschrieben und ihr einen namen gegeben.
das ist natürlich historisch gesehen ziemlicher quark - aber es soll verdeutlichen, dass man wenn man einer lösung einen namen gibt lediglich die kommunikation über die lösung verbessert, nicht aber das wissen über die lösung.
deshalb sind design pattern interessant von einem kommunikativen standpunkt aus gesehen - aber man kann auch ohne probleme ohne pattern zu kennen die gleichen probleme auf die gleiche art lösen wie mit einem pattern katalog.
pattern zu kennen macht einem deswegen nicht zu einem besseren architekten.
-
Wenns danach geht braucht man gar nichts wissen, weil man sich alles auch aus dem Nichts herleiten kann. Mit so einer Argumentation kannst Du jede Diskussion ad-absurdum führen.
Natürlich ist man nicht automatisch ein toller Software-Architekt, wenn man die Design Patterns kennt. Aber wenn man sie kennt, verstanden und verinnerlicht hat, dann ist das sicherlich wertvoller, als wenn jemand jedes Mal das Rad neu erfindet.
-
byto schrieb:
Wenns danach geht braucht man gar nichts wissen, weil man sich alles auch aus dem Nichts herleiten kann. Mit so einer Argumentation kannst Du jede Diskussion ad-absurdum führen.
Natürlich ist man nicht automatisch ein toller Software-Architekt, wenn man die Design Patterns kennt. Aber wenn man sie kennt, verstanden und verinnerlicht hat, dann ist das sicherlich wertvoller, als wenn jemand jedes Mal das Rad neu erfindet.Der Punkt ist, Design Pattern sind Namen. Nicht mehr.
Die Lösungen sollte man schon kennen, aber DP sind nur standardisierte Namen für Lösungen - mehr nicht.Nix herleiten oder so.
Wenn ich a2+b2=c^2
kenne, dann kann ich damit rechnen.muss ich wissen wie man diese formel nennt um sie anwenden zu können?
selbes mit dp. man wendet idR millionen mehr dp an als man selber kennt.
-
Shade Of Mine schrieb:
Der Punkt ist, Design Pattern sind Namen. Nicht mehr.
Das ist in der Konsequenz falsch. Die Patterns sind wiederkehrende Muster. Ein Pattern entsteht, wenn man so ein Muster in einem Design entdeckt. Am Anfang hat es noch gar keinen Namen. Dann arbeitet man die wesentlichen Strukturen heraus, abstrahiert das ganze auf das wesentliche, diskutiert die Konsequenzen usw. und gibt dem Kind schließlich einen Namen. Der Name ist wichtig, aber nur ein Teil.
Mit mathematischen Sätzen ist das übrigens überhaupt nicht vergleichbar. Der Patternbegriff kommt ja aus der Architektur. Ich habe das Originalbuch dazu zwar nicht gelesen (und wüßte auch nicht, wozu ich das tun sollte), aber da könnte es z.B. ein Muster "Tür" geben. Löst das Problem, dass man in einen Raum gelangen möchte, der durch eine Wand von einem getrennt ist. Man könnte auch ein Loch in die Wand hauen, aber irgendwie hat sich das Muster "Tür" durchgesetzt. Ist jetzt "Tür" nur ein Name? Würde man Häuser bauen können, ohne den Begriff "Tür" je gehört zu haben?
-
Shade Of Mine schrieb:
Der Punkt ist, Design Pattern sind Namen. Nicht mehr.
Wikipedia schrieb:
Namen sind, nach der aktuellen wissenschaftlichen Forschung, ein Zugriffsindex auf eine Informationsmenge über ein Individuum.
Wenn Design Patterns nur Namen sind, kann man damit ja nicht viel tun. Also z.B. kann man kein Singleton implementieren - denn Singleton ist nur ein Name! Namen bezeichnen aber etwas (jedoch niemals Design-Patterns!). Würde Singleton ein Design-Pattern bezeichnen, hätten wir nur wieder einen weiteren Namen usw.
Aber halt, ich liege falsch. "Design Pattern" ist dann ja selbst nur ein Name, wie kann ich darauf nur auf KnowledgeOfMankind["Design Pattern"]["Singleton"] schließen. Ab sofort sollten wir uns deshalb die richtige Schreibweise angewöhnen, indem wir den Indizes "KnowledgeOfMankind" voranstellen und die entsprechenden Zugriffsoperatoren benutzen.
Danke, dass du uns auf dieses Fehlverhalten der Menscheit aufmerksam gemacht hast, Shade of Mine!
-
Bashar schrieb:
Ein Pattern entsteht, wenn man so ein Muster in einem Design entdeckt. Am Anfang hat es noch gar keinen Namen.
Warum gab es die Lösungen dann bevor sie in Design Pattern Kataloge aufgenommen wurden?
bei DP ist es eben so rum, dass bestehende Lösungen einfach in einen katalog aufgenommen wurden. man hat schon ewig davor genau die gleichen methoden verwendet und ihnen halt 100.000mio unterschiedliche namen gegeben.
dp haben diese namen standardisiert.
aber sie haben keine neuen lösungswege erschaffen - sie haben ein vokabular definiert um sich austauschen zu können.@Mein Schatten:
ich sage ja dass die Namen sehr praktisch zum referenzieren der daten sind - aber die daten existieren auch ohne dass man ihnen einen namen gibt.
-
Shade Of Mine schrieb:
Warum gab es die Lösungen dann bevor sie in Design Pattern Kataloge aufgenommen wurden?
Was willst du mit solchen Fragen bezwecken?
Was ein Design Pattern ist steht auf den ersten zwei Seiten in "Design Patterns", damit können wir das Thema hoffentlich abhaken.
dp haben diese namen standardisiert.
Ja, die Namen für Design Patterns wurden standardisiert. Ein Design Pattern hat einen Namen. Es ist kein Name.
-
Name -> Muster
-
Ich finde das hat schon fast was philosophisches: Ein Tisch ist kein Tisch, er ist nur der Name eines Tisches!
-
Design Patterns sind nur was für BWL-N00bs, damit sie wieder ein paar neue Buzzwords haben. Echte Programmierer brauchen keine Patterns.
-
man muss es relativ sehen
ich entwickelte schon seit geraumer zeit bevor ich das pattern buch las
und dabei entdeckte ich parallelen wo ich erkannte das ich das schon lange so gemacht habzb hatte ich ein singleton verwendet ohne zu wissen das es einer ist bis ich darueber las
"echte programmierer" brauchen kein pattern, das stimmt, denn echte programmierer entwickeln software architektur die problemlos als ein oder mehrere pattern dargestellt werden koennen
-
Mr Evil schrieb:
"echte programmierer" brauchen kein pattern, das stimmt, denn echte programmierer entwickeln software architektur die problemlos als ein oder mehrere pattern dargestellt werden koennen
"echte programmierer" brauchen auch keine IDE, keine Dokumentation und keine Tests. :p
-
Echte Programmierer programmmieren nicht!