[OOP] Abhängige und doch wiederverwertbare Klasse...
-
Hi,
Beispiel:
Man schreibt eine Spriteklasse und hat einen Texturmanager.
Jetzt, weil der Texturmanager sich anbietet, möchte man die Spriteklasse abhängig von diesem machen. Der Texturmanager wiederum ist abhängig von dem Core...
Wenn so eine Struktur aufgebaut wird, lässt sich dort schlecht etwas herausnehmen, z.B. den Texturmanager oder die Spriteklasse.
Ich dachte jetzt daran, und das will ich gerne kommentiert haben, ob es nicht sinnvoll ist, dass Klassen, die Abhängikeiten aufbieten zusätzlich eine abstrakte Basisklasse für Erleichterungen bereiten.
Z.B. bietet die Spriteklasse dann ein Interface für einen Texturmanager.
Dann kann man entweder via Zeiger im ctor eine abgeleitete Klasse des Texturmanagers übergeben oder, wenn nicht, nimmt die Spriteklasse eine Alternativmethode an.
So lässt sich z.B. die Spriteklasse einfach aus dem System herauslösen.Wenn man jetzt natürlich den Texturmanager von der Basisklasse der Spriteklasse ableiten würde, so hätte man hier nicht mehr die Möglichkeit den Texturmanager herauszunehmen, daher könnte man:
a) Es dabei belassen, zur Wiederverwertbarkeit muss man dann nur die Ableitung wegmachen.
b) Einen Texturmanager erstellen und dann eine Klasse von diesem und der abstrakten Basisklasse, die die Spriteklasse bereitstellt, erben lassen.
c) (man inkludiert ja den Header der Klasse), folgende Konstruktion:#ifndef BASISKLASSE_BEREITGESTELLT_VON_SPRITE class BASISKLASSE_BEREITGESTELLT_VON_SPRITE {}; #endif
und dann erben lassen, BASISKLASSE_BEREITGESTELLT_VON_SPRITE ist ein Makro, dass simplerweise bei der Deklaration der Basisklasse, bereitgestellt von der Spriteklasse,
gesetzt wird.
c) gefällt mir stilistisch am Besten, aber vielleicht leide ich ja unter Geschmacksverirrung.
Mit diesem Konzept will ich besonders die Wiederverwertbarkeit erhöhen.
Fragen:
- Was haltet ihr davon?
- Wieso gefällt es euch denn nicht?
a)
Macht eine ungenutze Klassendeklaration den Code der ausführbaren Datei (b) wie heißt der allg. Begriff? EXE ist nur Window-spezifisch ende b)) (führe a) weiter) größer oder das Programm langsamer?Naja, das sind so Überlegungen, auf diese Weise kann man butterweich die Spriteklasse oder auch den Texturmanager herauslösen.
Beim Texturmanager hat man einfach nur eine Klasse, die von einer leeren Klasse erbt, wenn es keine Spriteklasse gibt. Falls doch, so erbt sie automatisch von der abstrakten Basisklasse, die die Spriteklasse bereitstellt.Die Feinheiten könnte man später noch ausmerzen, falls das Konzept im Groben gut wäre. Ein Problem (Frage 4) ist es überhaupt eines?) ist ja z.B. auch, dass die Namen des Texturmanagers nicht frei bestimmt werden können, da sie ja von der abstrakten Basisklasse, bereitgestellt von der Spriteklasse, bestimmt werden.
MfG MAV
PS: Ich weiß, ich hätte ein typedef für ,,abstrakte Basisklasse, bereitgestellt von der Spriteklasse'' deklarieren sollen. (Frage 5) handelt es sich hierbei überhaupt um eine Deklaration?)
-
Schau dir mal das Dependency Inversion Principle an. http://www.objectmentor.com/resources/articles/dip.pdf
-
Mach ich, demnach ist mein Konzept völlig unbrauchbar, ok...
Aber ist es nicht doof, wenn man immer nur fremde Konzepte verwendet und keine eigenen?
Dann kann man doch gleich andere programmieren lassen, oder?OK, ich will aber jetzt auch mal wissen, was an meinem Konzept so beschissen ist, bitte.
Sonst lern ichs doch nie...
-
Zieh Dir das CORBA- oder COM_Konzept rein und lern coden.
-
Denkst du, durch das Übernehmen eines OOP Designs hat man Coden gelernt? Sicher nicht.
Aber gut, wie arbeitet com denn?
Hat für alles Interfaces, die man dann mit einer abgeleiteten Klasse und 'nem Zeiger instanziiert, was ist daran so toll?
Oder wie läuft das?AFAIK nutzt DX COM, aber da ist doch alles voneinander abhängig, ist es überhaupt wichtig, dass der Code widerverwertbar ist? Ich dachte, das wäre ein grundlegender Teil von OOP...
Bitte net ständig auf irgendwelche Konzepte etc. verweisen sondern mal meines (stark) kritisieren, ich habe keine Ahnung, warum das anscheinend überhaupt nichts wert ist, sagt mal was zu.
Ich kann eben nicht konzipieren, lern ich so auch net, wenn mir keiner sagt, was Sache ist.
MfG MAV
-
Mis2com schrieb:
Denkst du, durch das Übernehmen eines OOP Designs hat man Coden gelernt? Sicher nicht.
nee. man muß schon hunderte übernehmen.
aber dummerweise wirste das nie, wenn du schon beim ersten bockst.
-
Mis2com schrieb:
Denkst du, durch das Übernehmen eines OOP Designs hat man Coden gelernt? Sicher nicht.
lol ignoranz
Mis2com schrieb:
Aber gut, wie arbeitet com denn?
Hat für alles Interfaces, die man dann mit einer abgeleiteten Klasse und 'nem Zeiger instanziiert, was ist daran so toll?
Oder wie läuft das?IUnknown -------------- / | \ | / | \ | / | \ | / | \ | IFoo1 IFoo2 IBar1 | \ | / | \ | / | \ | / | Samplerklasse ---------| | | Benutzung
Also wenn du das net kapierst biste doof
Mis2com schrieb:
AFAIK nutzt DX COM, aber da ist doch alles voneinander abhängig, ist es überhaupt wichtig, dass der Code widerverwertbar ist? Ich dachte, das wäre ein grundlegender Teil von OOP...
Das ist bei jeder OOP Architektur wie COM oder CORBA wichtig, denk doch mal nach, das ist für Abwärtskompatibilität!
Mis2com schrieb:
Bitte net ständig auf irgendwelche Konzepte etc. verweisen sondern mal meines (stark) kritisieren, ich habe keine Ahnung, warum das anscheinend überhaupt nichts wert ist, sagt mal was zu.
Es ist scheisse, nicht durchdacht und total fehl am platze.
Mis2com schrieb:
Ich kann eben nicht konzipieren, lern ich so auch net, wenn mir keiner sagt, was Sache ist.
Habe dir gesagt was sache ist also mach google an und lern!
-
Hoffentlich ist das Thema hier beendet, da hier der Umgangston langsam immer unfreundlicher wird will ich mir gar nicht vorstellen wie der nächste Beitrag aussehen würde.
-
Zu den beiden Fragen bei Punkt 3:
a) Nein, eine ungenutzte Klassendeklaration wird AFAIK einfach ignoriert und macht das Programm
weder größer noch langsamer.b) Allgemeiner Begriff für "ausführbare Datei" = binary.
gruß,
walker
-
Ich will einfach mal konstruktiv auf dein Posting eingehen, jedoch ohne direkt auf jede deiner einzelnen Fragen direkt einzugehen.
Meiner Meinung nach ist der Spruch "Alles muß irgendwie irgewo widerverwendbar sein, sonst ist es kein schönes Design!" totaler Unsinn! Sicherlich, WENN es denn so umgesetzt wird, dann Respekt! Aber ich finde, man muß es nicht. Man sollte sein Design so auslegen, das es die eigenen Anforderungen erfüllt, die man sich selbst stellt.
Willst du denn, das deine Klassen einzeln überall genutzt werden sollen? Wenn nicht, dann würde ich es auch nicht mit Brechen und Biegen versuchen.
Du willst ja ein Framework bauen, in dem sich ein Benutzer bewegen kann. Solange er sich aber in diesem Framework einfach bewegen kann, ist doch schon der Sinn dieses Framework erfüllt.
Meiner Meinung nach, heißt OO nicht gleich, das man eine Klasse überall auf diesem Planeten unabhängig anwenden können muß. Aber wenn es innerhalb des Frameworks Probleme gibt, ist es wirklich schlecht designed.
-
Nagut, ich seh ein, dass Design ist Quatsch, habe ja nur auf unabhängige Wiederverwertbarkeit beachtet, aber unabhängige Wiederverwertbarkeit ist einfach Mist, das benötigt kein Schwein; so eine Aussage hätte mir als Antwort auch gereicht.
Wie COM funzt, kapier ich jetzt...
@volkard:
Ich habe bei dem gar nicht gebockt, nur ging es mir in dem Thread in erster Linie nicht darum, ich werde mir das Konzept sicherlich anschauen.
Aber auf Dauer ist es doch sicher besser sich aus den einzelnen Konzepten das Praktische rauszusuchen, zu verwenden und gut ist.Jedenfalls bin ich nicht sonderlich zufrieden, wenn ich ein Konzept übernehme, das tat ich schon einmal und dann kam einer:
Wenn du darauf jetzt selbet gekommen wärest, dann wär's gut gewesen.
Umformuliert:
Haste nicht selber gemacht, ist also scheiße.Ich schaue mir das Konzept, das mir Shade gegeben hat, dankbar an.
Dennoch konnte ich am Anfang nicht verstehen, was an meinem Konzept so beschissen war, ich hätte mit einer klaren Aussage mehr anfangen können.
(Achtung, das ist keine Kritik sondern eine Erklärung zu meinem Verhalten)Danke jedenfalls,
MfG MAV
-
Mis2com schrieb:
Nagut, ich seh ein, dass Design ist Quatsch, habe ja nur auf unabhängige Wiederverwertbarkeit beachtet, aber unabhängige Wiederverwertbarkeit ist einfach Mist, das benötigt kein Schwein; so eine Aussage hätte mir als Antwort auch gereicht.
Hab ich doch geschrieben!
Mis2com schrieb:
Aber auf Dauer ist es doch sicher besser sich aus den einzelnen Konzepten das Praktische rauszusuchen, zu verwenden und gut ist.
Jedenfalls bin ich nicht sonderlich zufrieden, wenn ich ein Konzept übernehme, das tat ich schon einmal und dann kam einer:
Wenn du darauf jetzt selbet gekommen wärest, dann wär's gut gewesen.
Umformuliert:
Haste nicht selber gemacht, ist also scheiße.Hem, wer sagt sowas? Es gibt doch bewährte Konzepte. Man muß sich nur mal die vielen Bücher anschauen, die sich mit Design-Patterns befassen.
Und ich sage immer: Lieber gut geklaut, als schlecht selbst ausgedacht!
-
Die Idee von COM oder auch dem, was in dem PDF steht, (bin noch net durch) ist jedenfalls molto bene, die werde ich übernehmen, auch wenn man mich deswegen verurteilt, das ist mir egal, ich würde es selber niemals besser können.
MfG MAV
-
Nochmals hi!
Also vergesst das obige Design bitte, das ist Schwachfug, seh' ich ja ein.
Nun aber die Frage (ich beziehe mich jetzt auf COM bzw. das, was Shade mir als Link gab):
- Ist diese Art des Designs veraltet? Ich hatte so etwas gehört.
- Sollte man auch wirklich kleine Sachverhalte überhaupt so ausführlich und korrekt behandeln? Sollte man auch in kleinen Projekten für jede Beziehung gleich so handeln und Interfaces anlegen?
Ich frage deswegen, weil ich hörte, dass es absolut unsinnig ist so genau darauf zu achten, aber es klingt ja irgendwie ziemlich korrekt, schadet es eurer Meinung nach der Übersicht?
Sollte man Interfaces auch da platzieren, wo es unrealistisch, wenn aber auch möglich, ist hier eine andere Klasse für etwas bestimmten Wunsch zu nutzen? (also auch in Verbindung mit dem Konzept)Das kriecht mir noch etwas im Kopf rum, ansonsten sieht das gut aus, das werde ich wohl übernehmen, auch wenn ich deswegen blöd angemacht werden sollte :(,
MfG MAV, danke nochmals für den Link
-
so richtig?
Jede Klasse basiert auf einem eigenen Interface.
Klassen werden dann nurnoch über ihr eigenes interface angesprochen,sodass es im endeffekt für andere Klassen welche auf dieses Interface zugreifen absolut keinen Unterschied macht, wie die untergeordnete Klasse arbeitet.also würde man bei einer Klasse auto nicht die funktion anlassen benutzen-eben weils unterschiede zwischen normal und automatik gibt, sondern nur die virtuelle methode anlassen verwenden,und die untergeordnete Klasse entscheidet dann selber, was gemacht werden muss.
//edit also könnte man designtechnisch erst mit den interfaces anfangen,und wenn man mit dem design zufrieden ist entscheiden, wie die untergeordneten Klassen der interfaces arbeiten sollen..richtig?
-
Hi,
ja, so, wie du sagst, sollte es sein.
Man ruft die rein virtuellen (virtuell alleine macht aus der Klasse keine abstrakte Basisklasse) Methoden des Interfaces auf (Interface bedeutet m.W., alle Funktionen der Klasse sind rein virtuell).
Eine ziemlich gute Methode, mit der man Änderungen leicht vollführen kann und auch jederzeit etwas hinzufügen kann.
Dennoch habe ich immernoch die Fragen:Ist das Design in irgendeiner Weise veraltet?
Sollte man es strkt auch für kleinere Programmteile in kleinen Projekten anwenden?MfG MAV
-
das problem an dem design ist, dass es nur sehr begrenzt mit templates zusammenarbeitet..aufjedenfall bei template methoden gibts arge schwierigkeiten..
-
Hmmm, wieso?
-
template<class T> virtual void do_sth(T)=0;//fehler
aufjedenfall geht das beim bcb nicht,ich glaub das hat was mit der dynamischen bindung der funktion zu tun..
musste grad meine stream klasse deshalb umschreiben...ich arbeite jetzt überall mit den dummen void zeigern^^
-
otze schrieb:
musste grad meine stream klasse deshalb umschreiben...ich arbeite jetzt überall mit den dummen void zeigern^^
Vielleicht hilft dir ja http://www.schornboeck.net/artikel/virtual_template.htm ?