Welche Design Patterns funzen nicht in VB?
-
Hi Leute,
welche Design Patterns funzen nicht in VB und können auch nicht "simuliert" werden?
Ich lade gerade den Revolver und will die Platzpatronen weglassen!
cu
P84
-
ich glaub simulieren kannste alle
-
net schrieb:
ich glaub simulieren kannste alle
Dann simuliere mir mal bitte "Abstract Factory" in VB...
-
Prof84 schrieb:
net schrieb:
ich glaub simulieren kannste alle
Dann simuliere mir mal bitte "Abstract Factory" in VB...
ich habe kein vb aber ich schätze ein geübter vb-user könnte das hinkriegen
edit: guckst du hier --> http://www.codeguru.com/Csharp/.NET/net_general/patterns/article.php/c4673/
-
-
net schrieb:
Prof84 schrieb:
net schrieb:
ich glaub simulieren kannste alle
Dann simuliere mir mal bitte "Abstract Factory" in VB...
ich habe kein vb aber ich schätze ein geübter vb-user könnte das hinkriegen
edit: guckst du hier --> http://www.codeguru.com/Csharp/.NET/net_general/patterns/article.php/c4673/Ich glaube Prof84 meint Visual Basic 6.
-
Pattern sind sprachunabhängig (oder sollten es sein).
-
interpreter schrieb:
Pattern sind sprachunabhängig (oder sollten es sein).
naja, aber mit nicht-oo sprachen kann's schon recht schwer werden
-
net schrieb:
interpreter schrieb:
Pattern sind sprachunabhängig (oder sollten es sein).
naja, aber mit nicht-oo sprachen kann's schon recht schwer werden
Ja. Ich wollte nur anmerken, dass Pattern allgemeine Designmustern zur Lösung bestimmter, oft auftretender Probleme sind, und nicht ein tolles Feature einer bestimmten Sprache.
-
@interpreter
aber Designpattern stellen schon Anforderungen an die verwendete Programmiersprachen und die mitgelieferten Sprachmerkmale bzw. in wie fern man sie emulieren kann (so könnte man auch in C komplette Objekt Orientierung nachmachen)
-
Die Unterlagen, die ich bis jetzt zu Pattern durchgelesen habe waren alle abstraktater Natur und gingen nie auf eine Programmiersprache ein. Dass ein Pattern in der einen oder anderen Sprache schwerer (oder garnicht?) zu realisieren ist als in einer anderen ist klar.
-
Hallo,
nachdem jetzt die Existenzberechtigung meiner Frage geklärt ist...
Habt Ihr auch Antworten?
-
Grundsätzlich müssten doch alle funktionieren... nur die Implementation wird beliebig giftig und unleserlich (bzw. das Pattern ist nicht mehr erkennbar).
Es fängt mit diesen Pattern für Factorys an... in C++ sind die über Templates beliebig einfach zu implementieren, aber bereits unter Java oder C# benötigt man doppelten Code für jedes erzeugbare Objekt. Aber es lässt sich umsetzen.
Unter VB6 muß man aber zu allem Überfluss dann auch noch Objekte und virtuelle Methoden simulieren, weil das Dingenskirchens keine Objekte kennt - vor allem die Simulation virtueller Funktionsaufrufe macht das dann sehr unschön.
Ich vermute daher mal, daß eine wirkliche Umsetzung halbwegs lesbaren Code nur dann erzeugt, wenn man so eine Art Zwischencompiler einsetzt, der einem für typische OO-Features (Objekte erzeugen, zerstören, virtuelle Funktionen) VB-Code automatisch generiert.
-
Marc++us schrieb:
Grundsätzlich müssten doch alle funktionieren... nur die Implementation wird beliebig giftig und unleserlich (bzw. das Pattern ist nicht mehr erkennbar).
Grundsätzlich müsste Wasser auch den Berg rauf fließen!
Kommt ja auch nur auf die Stromgeschwindigkeit an.
Marc++us schrieb:
Unter VB6 muß man aber zu allem Überfluss dann auch noch Objekte und virtuelle Methoden simulieren, weil das Dingenskirchens keine Objekte kennt - vor allem die Simulation virtueller Funktionsaufrufe macht das dann sehr unschön.
Bingo! - Daher meine Frage!
Marc++us schrieb:
Ich vermute daher mal, daß eine wirkliche Umsetzung halbwegs lesbaren Code nur dann erzeugt, wenn man so eine Art Zwischencompiler einsetzt, der einem für typische OO-Features (Objekte erzeugen, zerstören, virtuelle Funktionen) VB-Code automatisch generiert.
MSDN Technical Note 220820041235:
....
For using design patterns download new SP Marcus++ 6 Patch !
It converts VB 6.0 ' dream remarks (wishlists)' to VC++ 6.0 codes, deploys design patterns and starts compiling ... !
-
wieso ärgerst du dich mit vb6 rum?
benutz doch eine neuere version oder ganz was anderes.
-
Prof84 schrieb:
Marc++us schrieb:
Unter VB6 muß man aber zu allem Überfluss dann auch noch Objekte und virtuelle Methoden simulieren, weil das Dingenskirchens keine Objekte kennt - vor allem die Simulation virtueller Funktionsaufrufe macht das dann sehr unschön.
Bingo! - Daher meine Frage!
Ja, aber daher verstehe ich sie auch nicht in der Tiefe... selbst so ein simples Ding wie ein Singleton wird wg. der fehlenden OO-Sprachelemente doch bereits beliebig unschön.
Eine Factory-Methode in VB zu implementieren ist natürlich möglich, aber alleine die Simulation der ganzen virtuellen Geschichten macht doch viele Dinge schlimmer als es nutzt.
Ich weiß nicht, wo man da die Grenze zwischen "realisierbar/nicht realisierbar" ziehen soll. Einige Fabriksachen könnte ich mir sogar noch gut vorstellen, schließlich muß da eine gekapselte Funktion nur Zeiger auf Strukturen zurück geben, damit hat man schon eine Art Fabrik. Um einen Ansatz zur Simulation von Objekten kommt man aber immer noch nicht herum, das dürfte wohl das Schlüsselelement für die Problemstellung sein.
Aber die Idee mit dem Zwischencompiler ist so abwegig nicht... man kann sich einige elementare Dinge überlegen die man braucht, wie Konstruktion/Destruktion und virtuelle Funktionstabellen, und man erstellt dafür eine Default-Implementation, die man dann einfach ersetzt. Ab einem gewissen Projektumfang dürften die Kosten für diese Sache akzeptabel werden.
-
net schrieb:
wieso ärgerst du dich mit vb6 rum?
benutz doch eine neuere version oder ganz was anderes.Das ist das Problem mit den Altlasten!
Wenn die Kunden ein VB Projekt mit siebenstelligen Etat entwickeln ließen,
an Ihre Grenzen bei der Weiterentwicklung stoßen,
mich beauftragen Lösungen für Ihr Kernteam zu entwickeln,
dass nur VB6 versteht und verstehen will ...
Ich persönlich finde VB zu kotzen.
Das ist aber nicht mein offizieller geschäftlicher Standpunkt!Marc++us schrieb:
...Ich weiß nicht, wo man da die Grenze zwischen "realisierbar/nicht realisierbar" ziehen soll....
Man kann halt aus 'nem Trabi kein Porsche bauen, ohne Materialkosten,
die über dem eines neuen Porsches liegen ...Alles was virtuelle Funktionen, overloads und "echte" Vererbung benötigt,
ist für mich mittlerweile tabu ...Marc++us schrieb:
Aber die Idee mit dem Zwischencompiler ist so abwegig nicht... man kann sich einige elementare Dinge überlegen die man braucht, wie Konstruktion/Destruktion und virtuelle Funktionstabellen, und man erstellt dafür eine Default-Implementation, die man dann einfach ersetzt. Ab einem gewissen Projektumfang dürften die Kosten für diese Sache akzeptabel werden.
Meta-Codegeneratoren sind schon geraume Zeit im Einsatz, nur sie stehen in Widerspruch zu meiner Entwicklungsphilosophie:
Niemals modernste Techniken einzusetzen, um die Unmodernsten zu erhalten!
-
interpreter schrieb:
Pattern sind sprachunabhängig (oder sollten es sein).
Sind sie nicht, und sollten sie auch nicht sein (siehe GOF S. 4, letzter Absatz in Abschnitt 1.1).
-
Bashar schrieb:
interpreter schrieb:
Pattern sind sprachunabhängig (oder sollten es sein).
Sind sie nicht, und sollten sie auch nicht sein (siehe GOF S. 4, letzter Absatz in Abschnitt 1.1).
Keine Ahnung was dein komischer GOF sein soll, aber Fakt ist, das Designpattern sprachunabhängig sind.
http://www.linuxmaniac.de/keyword/Design_Pattern.php"..So sind Entwurfsmuster zunächst einmal sprachunabhängig. "
http://www.zgdv.de/zgdv/Seminar/Rostock/Termine?nr=R054-025
"...Entwurfsmuster sind sprachunabhängig, ..."http://www.galileocomputing.de/openbook/java2/kap_06.htm
Die Anwort führt zwangsläufig zu Design-Pattern, sprachunabhängigen Gestaltungsmustern, die immer wiederkehren.Sorry, aber ich vertraue den zahlreichen Links und meinen Professoren
-
interpreter schrieb:
Keine Ahnung was dein komischer GOF sein soll, aber Fakt ist, das Designpattern sprachunabhängig sind.
Die GOF ist die "Gang Of Four". Die Autoren des Buchs "Design Patterns" bzw. "Entwurfsmuster".
EDIT:
Ich zitiere mal:
Die Wahl der Programmiersprache ist wichtig, weil sie den eigenen Blickwinkel beeinflußt. Unsere Muster basieren auf Smalltalk- oder C++-Sprachmitteln. Diese Wahl legt fest, was leicht und was nicht so leicht implementiert werden kann. Wären wir von prozeduralen Sprachen ausgegangen, so hätten wir vielleicht Muster wie "Vererbung", "Kapselung" oder "Polymorphie" aufgenommen. Auf ähnliche Weise werden manche unserer Muster von den weniger weit verbreiteten objektorientierten Sprachen direkt unterstützt. So verfügt CLOS beispielsweise über Multimethoden, was den Wunsch nach einem Muster wie dem Besuchermuster verringert. Die zahlreichen Unterschiede zwischen Smalltalk und C++ haben zur Folge, dass man manche Muster leichter in der einen als in der anderen Sprache umsetzen kann (siehe zum Beispiel das Iteratormuster).