Entwurfsmuster: Mehr als nur ein Elfenbeinturm?
-
Hallo,
ich bin Info-Student im letzten Jahr und habe kaum Praxiserfahrung.
Habe zwar privat viel programmiert aber nie an Projekten mitgearbeitet.Jetzt, in der Studienarbeit, entwickele ich ein objektorientiertes, verteiltes System. Alles schön und gut. Aber für elegante Entwurfsmuster sehe ich keine Anwendungsmöglichkeit.
Man hört auch immer wieder, dass in der Praxis viel Wartungsarbeit anfällt, und Systeme eher selten von Grund auf neu entwickelt werden. Das behindert die Anwendung von Entwurfsmustern auch sehr.
Ich würde von Praxiserfahrenen Entwicklern gerne mal wissen, ob oder wie oft superdurchdachte, elegante Entwurfsmuster eine Anwendung finden.
Oder ist das zu 99% wieder ein eher universitäres und nicht verwendetes Gebiet, vielleicht auch aus Zeitmangel wenn es eher auf Ergebnisse ankommt?Viele Grüße, tawa
-
Ja, ständig. Design Patterns habe ich nie als Elfenbeinturmmaterie empfunden, wie kommst du darauf?
-
tawa schrieb:
Jetzt, in der Studienarbeit, entwickele ich ein objektorientiertes, verteiltes System. Alles schön und gut. Aber für elegante Entwurfsmuster sehe ich keine Anwendungsmöglichkeit.
Das ist Übungssache. Man muss beim Entwurf schon erkennen, wo ein Designpattern angebracht ist. Im Normalfall nimmt man sich nicht ne Liste der bekannten Patterns und schaut welches man anwenden könnte, sondern überdenkt die Situation die man gerade entwirft und bemerkt dass das einem bestimmten Muster ähnelt, das man dann anwenden kann.
Man hört auch immer wieder, dass in der Praxis viel Wartungsarbeit anfällt, und Systeme eher selten von Grund auf neu entwickelt werden. Das behindert die Anwendung von Entwurfsmustern auch sehr.
Nur wenn in den bestehenden Systemen beim Entwurf keine entsprechenden Muster angewandt wurden. Meistens ist das aber der Fall, auch wenn man nicht jedes Muster sofort erkennt. Muster finden im Grunde auch nicht Anwendung in der Wartung sondern im Entwurf der Software (daher der Name ;))
Man darf Entwurfsmuster nicht dogmatisch betrachten, sie sind nicht in der Retorte entwickelt worden. Vielmehr ist es so, dass ähnliche Probleme meistens ähnlich gelöst werden, und die Gemeinsamkeiten dieser Lösungen sind dann ein Muster.
Betrachte das Muster "Rad". Niemand hat jemals "das RAD [TM]" erfunden. Vielmehr hat sich an vielen Orten zu verschiedenen Zeiten immer wieder gezeigt, dass eine runde Form eine gute Fortbewegung ermöglicht, und es gab schon immer viele Ausprägungen des Rades. Genauso ists bei Entwurfsmustern in der Software, es gibt nicht "das Muster XY" in Reinform, sondern das Entwurfsmuster XY ist das Kernkonzept vieler Implementierungen die sich untereinander aber dennoch arg unterscheiden können.
-
Design Pattern sind nur Namen fuer Loesungswege. Nicht mehr und nicht weniger.
Das bedeutet nun aber, dass ich Anhand eines Design Pattern Katalogs einen Loesungsweg fuer ein bestimmtes Problem finden kann.
Design Pattern bauen sich deshalb natuerlich in der Designphase selber ein. Da man ja idR nicht das Rad immer neu erfindet sondern meistens bekannte Loesungswese geht. Somit sind Design Pattern ueberall vertreten.
Den groessten Nutzen haben Design Pattern IMHO in der Kommunikation. Es ist viel leichter ueber Probleme und Loesungen zu reden wenn sie Namen haben.
-
Entwurfsmuster sind die halbe Miete, sie verkörpern genau die Dinge, die gute Software ausmachen - wer viele Designpattern kennt, schreibt automatisch bessere Software (auch ohne ein Pattern konkret einzusetzen).
-
SingletonFactoryObserver schrieb:
Entwurfsmuster sind die halbe Miete, sie verkörpern genau die Dinge, die gute Software ausmachen - wer viele Designpattern kennt, schreibt automatisch bessere Software (auch ohne ein Pattern konkret einzusetzen).
Begründung?
-
Shade Of Mine schrieb:
SingletonFactoryObserver schrieb:
Entwurfsmuster sind die halbe Miete, sie verkörpern genau die Dinge, die gute Software ausmachen - wer viele Designpattern kennt, schreibt automatisch bessere Software (auch ohne ein Pattern konkret einzusetzen).
Begründung?
Habs doch schon begründet: "Sie verkörpern genau die Dinge, die gute Software ausmachen". z.B. `loose coupling', `open closed principle' usw. findet man in vielen Designpatterns wieder.
-
Design Patterns sind keine Kochrezepte, sondern bestehen unter anderem auch aus einer Begründung und einer Diskussion der Vor- und Nachteile. Wenn man also ein Pattern verstanden hat, heißt das, dass man auch die grundlegenden OOD-Prinzipien, auf denen diese Diskussion basiert, verstanden haben muss.
Damit hat man natürlich keine Prinzipien abgedeckt, zu denen man kein Pattern kennt oder nur welche, mit denen man sich nicht eingehend auseinandergesetzt hat. Design Patterns als Königsweg zum guten OO-Design würde ich also nicht unterschreiben.
-
SingletonFactoryObserver schrieb:
Habs doch schon begründet: "Sie verkörpern genau die Dinge, die gute Software ausmachen". z.B. `loose coupling', `open closed principle' usw. findet man in vielen Designpatterns wieder.
Nein, ich will wissen warum ich bessere Software schreibe wenn ich Pattern auswendig lerne.
-
Shade Of Mine schrieb:
Nin, ich will wissen warum ich bessere Software schreibe wenn ich Pattern auswendig lerne.
Die Frage hat Bashar jetzt schon recht gut beantwortet. Auswendig lernen hilft hier nichts, es geht natürlich darum, sie auch verstnaden zu haben.
-
SingletonFactoryObserver schrieb:
Die Frage hat Bashar jetzt schon recht gut beantwortet. Auswendig lernen hilft hier nichts, es geht natürlich darum, sie auch verstnaden zu haben.
Ah.
Aber Design Pattern sind nur Namen für bekannte Problemlösungen.Ergo sagst du: wenn ich Probleme lösen kann, dann kann ich Probleme lösen.
Wozu genau brauche ich dazu Design Pattern?
Pattern sind ein Vokabulbuch für Designer.Natürlich ist hilft es wenn ich mich mit Architektur-Problemen auskenne dabei gute Programme zu schreiben. Aber wo genau kommen hier Design Pattern ins Spiel? Warum muss ich Design Pattern kennen?
-
Also:
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). Nach einer intensiven Auseinandersetzung mit Design Pattern bin ich mir also über gute Softwareeigenschaften bewusst, welche in bestimmten Pattern besonders zum Tragen kommen. Gleichzeitig weiß ich natürlich auch über etwaige `pitfalls' bescheid.
Und dieses Wissen trägt zu besseren Code bei, ohne dabei konkret auf ein Design Pattern zu setzen. Man muss die Pattern so gesehen eigentlich nicht kennen, aber indem man sie studiert, lernt man auch Dinge über Softwaredesign, an einem isolierten Musterbeispiel.
Hoffentlich kannst du das jetzt so akzeptieren.
-
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).
Und wie genau war es möglich vor dem aufkommen des Design Pattern Hypes genau die selben Problemlösungen zu verwenden? Und auch über sie zu diskutieren und eben auch ihre vor und nachteile zu kennen?
IMHO kann man in deinen Aussagen einfach Design Pattern durch "beschäftigen mit Software Architektur" ersetzen und es würde passen.
-
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?