nicht angemeldet
gruss Daniel, hallo Cheatah,
Entwurfsmuster sind im Prinzip immer überflüssig, ...
eben nicht.
... haben meiner Meinung nach aber zwei Vorteile:
- Dokumentation: ...
- Anregung für die Lösung: ...
...
Daniel
ich ergänze um einen dritten: Konzeption. Besonders bei
komplexeren Projekten können aufgezeichnete Pattern sehr
nützlich sein.Cheatah
ja, danke Euch beiden ...
... mir ist schon klar, was entwurfsmuster sind, was man
mit ihnen leisten und was man eben nicht erwarten kann.
und gerade weil die praxis nach punkt 3 verlangt, fragte
dann frag' ich mich aber auch, warum der OP den namen
des entwurfsmusters wissen wollte - dieser (den name)
ist fuer analyse und loesung des vom OP vorgestellten
---------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
------vvvvv
falls ohne bedeutung.
ich mich, warum der OP bei einem aus meiner sicht eher
trivialen problem das ganz grosse geschuetz auspacken
wollte ... ach nee, wollte er ja nicht, er hat nur nach
dem namen der waffe gefragt ;-)
Naja, er wusste da gibt es eine "fertige" Lösung. Mit dem
Namen hätte er sie nachschlagen und verwenden können.
---------------------------------------^^^^^^^^^
das bezweifle ich.
In diesem Fall dürften übrigens die Muster Composite und
Decorator relevant sein. ...
mit viel gutem willen, sehe ich da gerade noch so bedarf
fuer den "Dekorierer". ich mag abstraktion, und ich bin
sehr fuer denkmodelle, die mich beim abstraktionsprozess
leiten.
aber die *reine lehre* fuer das vom OP gegebene problem
durchzuexerzieren finde ich eher theoretisch interessant.
aus praktischer sicht (und da denke ich schon an pflege,
wartbarkeit, erweiterbarkeit - durchaus auch von dritten)
halte ich dies fuer *overkill* ...
@Daniel
... so wie Du augenscheinlich ja auch:
... Für die Frage, wie man die Panels nun genau an den
Controller hängt, helfen die Muster aber auch nicht
groß weiter.
warum hacke ich nun so darauf rum? ich bin persoenlich
sehr daran interessiert entwurfsprozesse, wie sie bei
den *serioesen programmierern* schon lange nicht mehr
wegzudenken sind, in teilen auch auf die entwicklung
von DOM-scripten/JavaScript-architekturen zu uebertragen.
literatur, die zu diesem thema aus breiter praxiserfahrung
schoepft, ist leider kaum vorhanden, obwohl ich jede wette
eingehe, dass Google seinen anwendungen solche prozesse
angedeihen laesst - die »Yahoo! User Interface Library«
hat das licht der welt sicher ebenfalls nicht durch
*extreme programming* erblickt.
betrachten wir z.b. mal folgende basale "Erzeuger"-muster:
- der "Prototyp": geil - ein grosser teil sex-appeal des
JavaScript-sprachkonzepts fusst auf konstruktoren und
eben prototypen.
- der "Erbauer": ein praxisrelevanter klassiker - ohne
erbauer kein cooles DOM-scripting. warum? weil gerade
die schoene neue oberflaechenwelt im hintergrund nach
vielschichtiger programmlogik verlangt. ein *builder*
parst in meiner idealen welt den DOM-baum, waehlt sub-
strukturen entsprechend ihrer css-klassen-namen und
fuehrt diese gegebenenfalls weiteren "Erzeuger"n zu.
- das "Singleton"-muster ist im JavaScript-kontext wichtig,
um z.b. die kapselung eigener komplexer namespaces zu
wie auch immer gearteten programmteilen dritter zu
gewaehrleisten und kann in seiner wasserfesten umsetzung
so aussehen:
~~~javascript var Singleton = new (function () { // new-operator und anonymer konstruktor;
//privater kram - z.b. durchaus auch weitere private konstruktor-funktionen.
this.constructor = Object; /* verhindert das erzeugen neuer instanzen
von [[Singleton]], was bis hierhin immer
noch in dieser art moeglich gewesen waere:
var Double = new Singleton.constructor();
*/
//oeffentlicher kram - z.b. eine einzige oeffentliche methode [build] oder [compile]:
this.compile = function () {
// z.b. die aufgaben eines "Erbauer"s.
};
})();/* der konstruktor wird unmittelbar nach der initialisierung durch den call-operator
ausgefuehrt und weggeschmissen bzw. bei der ausfuehrung intern ueberschrieben.
*/
mehr faellt mir auf die schnelle nicht ein und wuerde wohl auch
den rahmen sprengen. ich bin aber, wie schon gesagt, sehr daran
interessiert, dieses thema weiter zu eroertern.
by the way:
zarte andeutungen in diese richtung mache ich auch im nachwort
meiner [deutschen uebersetzung](http://www.pseliger.de/translations/Douglas-Crockford/missunderstood-JavaScript.html) von [Douglas Crockfords klassiker](http://javascript.crockford.com/javascript.html)
[»JavaScript: The World's Most Misunderstood Programming Language«](http://javascript.crockford.com/javascript.html).
so long - peterS. - pseliger@gmx.net
--
»Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies.
Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.« - [Douglas Crockford](http://javascript.crockford.com/)
ie:( fl:) br:> va:( ls:& fo:) rl:| n3;} n4:} ss:} de:µ js:} mo:? zu:]