Welche Design Patterns funzen nicht in VB?
-
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.