Auf Interface Programmieren



  • DocShoe schrieb:

    Hängt vom Anwendungsfall ab, du solltest erst ein mal erklären, was deine Managerklasse später können soll. Wenn es verschiedene konkrete Manager gibt, die sich in ihrem Verhalten unterscheiden, dann macht es Sinn. Einfach nur so jeder Klasse ein abstraktes Interface zu verpassen, nur um gegen das Interface programmieren zu können, macht keinen Sinn.

    Durchaus dachte ich daran das sich die Manager danach anders verhalten und mit Methoden erweitert werden oder eben nicht. Die Methoden wie Init(), Render() und Update() haben alle. Um sicher zu stellen, das diese auch vorhanden sind, dachte ich eben an eine Abstrakte Basisklasse, das dem Aufrufer garantiert, das diese Methoden Implementiert sind. Ob ein Manager dann um Methoden erweitert wird oder nicht, hängt dann von der Konkreten Implementierung ab. Diese wollte ich dann mit dem Strategy Pattern lösen.



  • CodeBase schrieb:

    Diese wollte ich dann mit dem Strategy Pattern lösen.

    Ich weise darauf hin, dass Strategy Patterns je nach Anwendungsfall durch std::function oder Policy-based Design gelöst werden, nicht durch Vererbung.

    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.



  • 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.

    Wegen dem Prinzip der Verschwiegenheit ?

    Es geht mir darum. Ich habe mich, vor längerer Zeit, mit C++ beschäftigt und auch das ein oder andere gemacht (was sicher nicht dem OO Entsprach, da bin ich ehrlich). Beruflich bin ich dann in die Datenbankentwicklung eingestiegen. Meine Passion liegt aber immer noch bei C++ und ich beschäftige mich seit einiger Zeit wieder intensiv damit. 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. Ich möchte einfach einen sauberen Wiedereinstieg schaffen und Fragen gleich im vorraus aus dem Weg räumen. Das Prinzip des "Code soll für Erweiterungen offen aber für veränderungen geschlossen sein", gefällt mir und ich versuche das gerade zu verinnerlichen und auch anwenden zu können. Steinigt mich bitte nicht wenn ich dumme Fragen stelle oder ausdrücke verwende die vll. nicht 100% passen (wie Inrerface zb. 🙂 )

    lg



  • 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 ?

    http://www.amazon.de/Modernes-Design-Programmierung-Entwurfsmuster-Professional/dp/3826613473/ref=reg_hu-rd_add_1_dp

    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

    http://sourcemaking.com/



  • 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.


Anmelden zum Antworten