Welche Design Patterns funzen nicht in VB?
-
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).
-
interpreter schrieb:
Keine Ahnung was dein komischer GOF sein soll
Solltest du aber, wenn du über Patterns diskutierst. Könntest du Wikipedia-Artikel, den du verlinkt hast, ja auch mal selbst lesen.
Sorry, aber ich vertraue den zahlreichen Links und meinen Professoren
Dein Problem.
Patterns sind insofern sprachunabhängig, als dass sie nur grobe Anforderungen an das Objektsystem stellen. Java, C# und C++ sind sich da relativ ähnlich, und UML ist diesen Sprachen angepasst: Single-Dispatch-Polymorphie, statische Typung, Einfachvererbung von Implementierungen und Mehrfachvererbung von Interfaces können die alle. C++ kann auch Mehrfachvererbung von Implementierungen, und schon taucht ein Pattern auf, was das benötigt, und du folglich in Java gar nicht realisieren kannst: Stairway to Heaven.
Aber sowie sich diese abgesteckten Grenzen verschieben, schrumpfen einige Patterns bis zur Unkenntlichkeit, z.B. was soll man mit Command, wenn man First-Class-Funktionen hat? Was soll man mit einer Factory, wenn es First-Class-Typen, Metaklassen oder dergleichen gibt?
-
Bashar schrieb:
interpreter schrieb:
Keine Ahnung was dein komischer GOF sein soll
Solltest du aber, wenn du über Patterns diskutierst. Könntest du Wikipedia-Artikel, den du verlinkt hast, ja auch mal selbst lesen.
Habe ich gerade. Aber abgesehen davon, dass ich jetzt weiß GOF is, brachte es kaum neue Erkenntnisse und bestätigte mich.
Dein Problem.
Problem, hm... irgendwie seh ich gerade keins.
Patterns sind insofern sprachunabhängig, als dass sie nur grobe Anforderungen an das Objektsystem stellen. Java, C# und C++ sind sich da relativ ähnlich, und UML ist diesen Sprachen angepasst: Single-Dispatch-Polymorphie, statische Typung, Einfachvererbung von Implementierungen und Mehrfachvererbung von Interfaces können die alle. C++ kann auch Mehrfachvererbung von Implementierungen, und schon taucht ein Pattern auf, was das benötigt, und du folglich in Java gar nicht realisieren kannst: Stairway to Heaven.
Aber sowie sich diese abgesteckten Grenzen verschieben, schrumpfen einige Patterns bis zur Unkenntlichkeit, z.B. was soll man mit Command, wenn man First-Class-Funktionen hat? Was soll man mit einer Factory, wenn es First-Class-Typen, Metaklassen oder dergleichen gibt?
Design-Pattern sind sprachunabhängig. (Das Zitat von Gregor, das, wie ich mal vermute, von der GoF stammt, sagte auch nirgends, dass Design-Pattern sprachabhängig sind). Dass man einige in manchen Sprachen schwerer umsetzen kann als in anderen wurde in dem Thread ja bereits geklärt. Mag sein, dass hier Stairway to Heaven aus dem Rahmen fällt.
-
Du solltest mal Deine Professoren und Links befragen, was sie unter "Sprachen" verstehen... wahrscheinlich kommt dabei raus, daß sie OO-orientierte-Sprachen meinen.
Ich stelle mir die Realisierung einer virtuellen Fabrik unter Assembler eher... anspruchsvoll vor. Ebenso werden Pascal oder VB mit einer Vererbungshierarchie zu knabbern haben. Die Äußerung, daß Pattern global gesehen sprachunabhängig sind macht nicht so dramatisch viel Sinn. Man wird hier sicherlich noch weitere Einschränkungen bzgl. des hinterlegten Paradigmas der Implementierungssprachen einfordern.
Da die Pattern eher aus der OO-Welt stammen, wird wohl jeder innerhalb dieses Begriffsrahmens den Ausdruck "sprachunabhängig" auf die Mainstream OO-Sprachen Smalltalk, C++, C#, Java beziehen.
-
interpreter schrieb:
(Das Zitat von Gregor, das, wie ich mal vermute, von der GoF stammt, sagte auch nirgends, dass Design-Pattern sprachabhängig sind). Dass man einige in manchen Sprachen schwerer umsetzen kann als in anderen wurde in dem Thread ja bereits geklärt.
Patterns sind zunächst mal Problemlösungen. Diese Probleme schweben aber nicht im luftleeren Raum, sondern kommen direkt oder indirekt daher, dass eine Sprache bestimmte Vorhaben nicht unterstützt. Beispielsweise muss an dem Punkt, an dem eine Instanz einer Klasse erzeugt werden soll, in C++ zur Übersetzungszeit bekannt sein, welche Klasse das sein soll: new Foo(). Wenn man Klassen als Objekte behandeln könnte, über die dann der Instanziierungsprozess zur Laufzeit parametriert werden würde, wär das nicht notwendig. Das Factory-Pattern kann man anwenden, wenn man nur C++ o.ä.zur Verfügung hat. Dieses Pattern löst also direkt ein Problem einer bestimmten Klasse von Programmiersprachen, von denen C++ ein Vertreter ist.
Bei anderne Patterns sträubt man sich vielleicht dagegen, das zugrundeliegende Problem einer Sprache zuzuordnen. Dann liegt das Problem eben in der benutzten OOD-Methodologie bzw. Modellierungssprache. Das Visitor-Pattern löst z.B. ein Problem, das dem Single-Dispatch-Objektsystem von C++, Java usw. inhärent ist. Klassen sind abgeschlossene Einheiten, und es entscheidet stets das Objekt, an das eine Nachricht gesendet wird, was es damit tut. Das Hinzufügen einer Operation zu allen Klassen einer Hierarchie ist damit eigentlich nur zu bewerkstelligen, in dem man alle Klassen modifiziert. Oder mithilfe des Visitor-Patterns. Wenn man allerdings eine Sprache nutzt, die ein anderes Objektsystem mit Multiple-Dispatch verwendet, löst sich das Problem, und damit die Notwendigkeit des Patterns, in Luft auf.
Genau wie die motivierenden Probleme, entstammen auch die Lösungen, also die Beschreibungen der Patterns, einer OOD-Methodologie und damit einer Klasse von Sprachen.
-
Wie immer liegt die Wahrheit wohl in der Mitte. Die Aussage "Pattern sind sprachunabhängig" ist in der Tat mit Vorsicht zu genießen, weil alle Pattern letztlich doch gewisse Sprachkonstrukte benötigen, um effizient implementiert werden zu können. Mir war lediglich die Formulierung "Pattern sind sprachabhängig" zu extrem, da sie den Eindruck vermittelt, dass z.B. Pattern A an Sprache X,Y und Z gebunden ist, obwohl es zur Umsetzung lediglich ein Paradigma/Sprachkonstrukte benötigt, dass Sprache X,Y und Z anbieten.