Auf Interface Programmieren
-
CodeBase schrieb:
Ein Freund gab mir das Buch "Entwurfsmuster von Kopf bis Fuß" (manche kennen das sicher). Das Problem daran ist das auf Java aufgebaut ist, aber die Pattern bleiben ja, vom Prinzip her, gleich.
Höhö, in Software Engineering hat der Dozent auf dieses Buch aufgebaut und es als Grundlage genutzt
Liest sich zwar gut, aber ist alles andere als wissenschaftlich...
Mit den Pizzas Hamburger Berliner und Münchner Art.
-
C++ bietet einfach mehr Mittel an. Die Entwurfsmuster von Java eignen sich solange auch für C++, wie man nicht bessere Lösungen nutzt. Mich regt an Java tierisch auf, dass man zig Interfaces und Klassen für die einfachsten Anwendungsfälle stricken muss (also bei einfachen Zusammenhängen, bei denen ein Design Pattern aber angebracht ist).
Edit: Und mich regt an Dozenten auf, dass sie denken, die Designpattern-Welt von Java ist die von jeder Sprache, schön alle Sprachfeatures, die bessere Lösungen zulassen, vernachlässigend, weil ja sowieso "jeder Java nutzt" oder "OOP eben OOP ist". Aber das nur nebenbei.
Wie man Strategy besser löst, hat oblase dann ja schon gesagt.
Anderes Beispiel ist Listener/Observer-Pattern, das löst man in C++ brav mit slots/signals (boost und QT bieten das an).
Grundsätzlich bietet C++ eine sehr starke statische Polymorphie an, was unter Java mit den schwachen Generics nur wenig ausgeprägt ist. Ich würde sagen, wenn zur Compilezeit Dinge feststehen können oder sollen, dann kann man sehr, sehr häufig (immer will ich mir nicht anmaßen zu sagen) auf viele Pattern Javas verzichten (oder diese abwandeln), weil man häufig keine Vererbung (auch von Interfaces) benötigt.
Kannst ja weitere Designpatterns zur Diskussion stellen, wenn Du Dir unsicher bist. Ich finde die Diskussion sehr interessant und ein Design-Pattern-Buch für C++ habe ich auch noch nicht gesehen (wäre aber meiner Meinung nach durchaus Mal angebracht).
-
Naja das Design-Patterns Buch von den GoF ist in C++ und Smalltalk implementiert...
Aber insofern hast du schon Recht, weil die 4 Kollegen nur die Prinzipien zeigen wollen und auch auf einfachste Features oder Must-Haves von C++ keinen Wert legen. Wenn ich mich recht erinnere, frickeln die an sehr vielen Stellen mit Pointern rum, anstatt Smart-Pointer oder Referenzen zu nutzen.
Auf so Geschichten wie Policy-Based Design (was ja letztlich nichts anderes ist, als das Strategy Pattern) wird auch nur auf die Möglichkeit über Vererbung eingegangen.In Java legt man vor allem sehr viel Wert darauf alles zur Laufzeit zu ändern oder anzupassen (zu können). Das ist schön!
Aber es verhindert Optimierungen, bremst dadurch die Performance und wird so oft nun auch nicht verwendet. Zumal es, wie ich finde, auch gar nicht mal so simpel ist mit Reflection und Spring und alles.Wie macht man das in C++?
Letztlich durch neucompilieren oder durch DLLs (oder halt das entsprechende Pendant auf dem jeweiligen System).
-
Wow da ist ja eine echte Diskussion losgebrochen :).
Also mir ist schon bewusst das, das Buch "Von Kopf bis Fuß" nicht unbedingt das beste Buch ist, aber es gibt einen einblick darauf wie Design Patterns funktionieren (ob alle bsp. jetzt 100% Passen sei mal dahin gestellt).
Zum Thema Buch, was haltet ihr von diesem ?
Prinzipiell finde ich Design Patterns eine schöne Sache. Besonders hatt es mir das Singelton Pattern angetan. Wobei ich hier auch schon viele meinungen über Statische Objekte gelesen habe.
-
Tja, das Buch ist gut, aber es ist schwer. Und so viel ist da nicht zu den herkömmlichen Patterns drin.
Aber Alexandrescu ist einer, der weiss wovon er spricht, äh schreibt. (nicht so wie JW)
Zum Singleton: Google einfach hier im Forum danach, du wünscht dir später du würdest diesen Begriff niemals gehört haben, so wird hier dafür oder dagegen geschrien
-
Stimmt da geht es gut ab
aber lassen wir die Diskussion nicht auf das Pattern rauslaufen das wird nichts ^^. Schreiben wir über die Factory Methode die ist interessant.Kennt jemand diese Seite
-
Nein, sehr interessant, aber sieht eigentlich genauso aus wie der entsprechende Wikipedia Artikel über Patterns und Anti-Patterns...
Factory Method Pattern = Template Method Pattern nur beim Erzeugen...
-
Kann mir das einer erklären ?
http://en.wikipedia.org/wiki/Curiously_Recurring_Template_Pattern
Irgendwie fühle ich mich gerade ein bisschen erschlagen und weiß gerade nicht was ich mir den jetzt genau anschauen soll und was nicht. Was gilt für C++ ? Was nicht ? Wo bekomme ich Pattern her die ich brauchen kann und wo werden die Beschrieben (vll. auch in Deutsch).
-
oblase schrieb:
Design Pattern sind für reine OOP-Sprachen mit begrenzten Mitteln. In denen schreibt man dann Code wie
Executer executer = Executer.getExecuter(); executer.execute();In C++ gilt das nicht unbedingt als guter Stil.
Die Aussage "Design Pattern sind für reine OOP-Sprachen mit begrenzten Mitteln" ist ja wohl ein noch viel schlimmerer Quatsch als das konkrete Beispiel das du bringst.
-
CodeBase schrieb:
ich habe mal eine Frage. Ich habe mal wo gelesen das man immer auf ein Imterface Programmieren soll und nicht auf eine Implementierung.
Jain. Gerade in C++ hast du mehrere Möglichkeiten dieser Art von Abstraktion. Man ist nicht auf Vererbung und virtuelle Funktionen beschränkt. Die Alternative heißt "generische Programmierung". Ich würde letzteres Vorziehen, weil es bzgl Performance kostenlos ist. Bei Gelegenheit kann man dann immer noch per Type-Erasure eine Art Laufzeitpolymorphie erhalten, beispielsweise Funktoren, die in einem std::function<>-Objekt drinstecken.
Ich habe als Java-nach-C++ Umsteiger auch anfangs solche abstrakten Klassen geschrieben, weil es der einzige Abstraktionsmechanismus war, der mir vertraut war. Das ist allerdings 5 Jahre her. Und heute schreibe ich ganz anderen Code. new/delete/virtual sind Dinge, die ich höchst selten verwende. Ich habe gelernt, dass es viele Fälle gibt, in denen man so einen Polymorphismus zur Laufzeit gar nicht braucht. Es reicht ggf die Parameterisierung von Funktionen und Klassen zur Compilezeit (--> Templates). Und selbst das sollte man auch nicht übertreiben.
-
CodeBase schrieb:
Kann mir das einer erklären ?
http://en.wikipedia.org/wiki/Curiously_Recurring_Template_Pattern
Irgendwie fühle ich mich gerade ein bisschen erschlagen und weiß gerade nicht was ich mir den jetzt genau anschauen soll und was nicht. Was gilt für C++ ? Was nicht ? Wo bekomme ich Pattern her die ich brauchen kann und wo werden die Beschrieben (vll. auch in Deutsch).
Mh, ich würd mir über die Zeit einfach mal alle Patterns angucken, dass du sie grundlegend verstehst (vllt mal implementieren) und weisst wofür und wann man die braucht.
Und irgendwann kommst du dann an nen Punkt, wo du was machen musst und dir kommt in den Kopf "Ach Moment, da gabs ja was" und dann suchste dir das entsprechende Pattern raus, liest es nochmal durch und nutzt es...
-
krümelkacker schrieb:
CodeBase schrieb:
ich habe mal eine Frage. Ich habe mal wo gelesen das man immer auf ein Imterface Programmieren soll und nicht auf eine Implementierung.
Jain. Gerade in C++ hast du mehrere Möglichkeiten dieser Art von Abstraktion. Man ist nicht auf Vererbung und virtuelle Funktionen beschränkt. Die Alternative heißt "generische Programmierung". Ich würde letzteres Vorziehen, weil es bzgl Performance kostenlos ist. Bei Gelegenheit kann man dann immer noch per Type-Erasure eine Art Laufzeitpolymorphie erhalten, beispielsweise Funktoren, die in einem std::function<>-Objekt drinstecken.
Ich habe als Java-nach-C++ Umsteiger auch anfangs solche abstrakten Klassen geschrieben, weil es der einzige Abstraktionsmechanismus war, der mir vertraut war. Das ist allerdings 5 Jahre her. Und heute schreibe ich ganz anderen Code. new/delete/virtual sind Dinge, die ich höchst selten verwende.
Heißt das, das Generische Programmierung das A und O heute ist ? Also nichts mehr mit new, pointern usw. ? Bin gerade etwas platt.
-
Doch Pointer schon, aber nicht mehr die regulären.
Smart Pointer ist das Stichwort.
-
Nathan schrieb:
Doch Pointer schon, aber nicht mehr die regulären.
Smart Pointer ist das Stichwort.auto_ptr, shared_ptr usw. ?
-
Ja.
Wobei eher unique_ptr.
-
Kann mir mal einer Zeigen, wie das Bsp. das ich gebracht habe (am anfang mit dem Managern) in der Generischen Programmierung umsetzten würde ?
-
CodeBase schrieb:
Heißt das, das Generische Programmierung das A und O heute ist ? Also nichts mehr mit new, pointern usw. ? Bin gerade etwas platt.
Ich denke nicht, dass das ein(e) erfahrene(r) C++ Programmierer(in) ernsthaft so behaupten kann. Stell Dir einfach C++ als eine verhältnismäßig große Werkzeugkiste vor. Da sind Werkzeuge drin, die dir bekannt vorkommen und welche, mit denen du im Moment noch kaum etwas anzufangen weißt. Das ist aber normal. Man kann nicht erwarten, dass Anfänger immer das "richtige Mittel" verwenden, um ein Problem zu lösen. Es braucht seine Zeit, um die Sprache in seiner Weite zu erfassen. Und es ist wohl auch normal, dass man von neu erlernten Dinge so begeistert ist, dass man die für alles Mögliche einsetzen will. Ich sage nicht, dass abstrakte Klassen und virtuelle Funktionen böse sind und heute nicht mehr benutzt werden sollten. Ich denke nur, dass man gerade als Umsteiger von Java solche Dinge eher überbeansprucht. Natürlich haben abstrakte Klassen und virtuelle Funktionen ihre Einsatzzwecke. Es gibt aber auch vieles, was man nicht in eine Klassenhierarchie zwängen und mit virtuellen Funktionen versehen muss.
Bzgl Deiner PM: Ich weiß gar nicht, welches Problem du mit diesen Klassen lösen willst. Von daher kann ich nur allgemein bleiben und nicht wirklich andere Vorschläge machen.
-
Danke auf jeden fall für die Antwort.
Was ich mit dem Problem lösen will ? Hmm eigentlich kein Konkretes, mir geht es um das verständnis. Ich will einfach lernen
-
Kann mir mal einer Zeigen, wie das Bsp. das ich gebracht habe (am anfang mit dem Managern) in der Generischen Programmierung umsetzten würde ?
Immer wenn ich Klassennamen sehe wie "TextureManager", "ObjectManager" oder Command.execute() sehe, vermute ich vom Design her startke Maengel. Warum? Erfahrung! Es gab meist einen Weg, es treffender, einfacher, arbeitssparender und generischer zu loesen.
Auch ist aus Meiner Sicht Vererbung eher hinderlich bei der Wiederverwendbarkeit von Klassen. Wenn sie in einem anderen Projekt benutzt werden soll, muss man den ganzen Rattenschwanz (oder gleich das ganze Framework) mitschleppen. Nachtraeglich kann eine Klasse immer in eine Vererbungshierarchie durch Adapter eingebracht werden. Herausnehmen ist ungemein schwieriger. Zwar sieht es total toll in Form von UML-Diagrammen aus, aber ist unglaublich unpraktisch. Nichtsdestotrotz hat Vererbung natuerlich Sinn, damit koennen beispielsweise gut Window-Toolkits aufgebaut werden. Ich kenne keines, dass nicht eine Basisklasse a la "Widget" hat, von denen abgeleitet wird.
Und bei Java faellt mir immer Execution in the Kingdom of Nouns ein. Auch zitiere ich gern:
Peter Norvig schrieb:
Study of the Design Patterns book: 16 of 23 patterns have qualitatively simpler implementation in Lisp or Dylan than in C++ for at least some uses of each pattern
Generische Programmierung das A und O heute ist ? Also nichts mehr mit new, pointern usw. ?
Quatsch. Auch glaube ich, dass du eine falsche Vorstellung von generischer Programmierung hast.
-
knivil schrieb:
Generische Programmierung das A und O heute ist ? Also nichts mehr mit new, pointern usw. ?
Quatsch. Auch glaube ich, dass du eine falsche Vorstellung von generischer Programmierung hast.
Das Glaube ich auch nur stehe ich gerade ein bisschen im Wald, weil das was ich bis jetzt als "richtig" angesehen habe, doch nicht richtig ist und man es anders löst. Bei mir fällt gerade alles zusammen weil ich einfach nimmer weiß, was jetzt richtig oder falsch ist. Bin nur im moment einfach ein bisschen gefrustet weil ich vererbung jetzt mal so richtig verstanden habe und jetzt stellt sich raus das es nicht richtig ist.
