Selbststudium OOP in C++

CarstenJ

Hi again,

ich habe auch ne Ausbildung zum Fachinformatiker gemacht, allerdings Systemintegration. Momentan suche in nen Job. Blamiert hast du dich nicht, für mich sah das nur teilweise so aus, als hättest du so gar keinen Bock selber zu denken. Aber ist aus der Ferne immer schwer zu beurteilen.

Das mit dem Pluginsystem ist doch schonmal ein Anfang. Ich persönlich finde, dass man so am besten und effektivsten lernt, natürlich neben dem Lesen und Durcharbeiten von Büchern.

Ich bin allerdings auch nicht bereit, es aufzugeben, weil es mir einen imensen vorteil bringt

Eigenintiative ist immer gut, hat mich auch vor dem Untergang bewahrt.

fluxy

hmmm,

ich mache meine Ausbildung in einer Firma im Technologiepark, kann mich ja mal umhöhren, aber das würde ich ehrlich gesagt nicht so gerne im Forum breittreten. Meine Emailaddresse steht ja da da kannste dich melden.

Was meine Motivation angeht:

Die ist durchaus vorhanden. Allerdings bin ich nicht grade der König, wenns um Google und Co. geht und finde relativ selten das richtige. Ich habe in der Regel auch mehr Zeit auf der Arbeit. Selber kann ich über mich sagen, dass ich nie zu faul bin zum denken. Aber manchmal denke ich auch zu kompliziert oder über zu viele Ecken, habe ich mir im Abi wohl angewöhnt.

Gruß Sebastian

Real

Versteh dich nicht.
Java ist optimal für den Anfang was Objektorierung und sauberer Code angeht.
Fang doch damit an.
Könnte dir auch ein bisschen helfen wenn du willst.

Liebe Grüße
Real

007ski

fluxy schrieb:

Hallo,
ich mache leider grade eine Ausbildung zum Fachinformatiker, Anwendungsentwicklung

warum leider

Korbinian

Real schrieb:

Java ist optimal für den Anfang was Objektorierung und sauberer Code angeht.

das versteh jetz ich nicht nur weil bei java alles zwanghaft in klassen gelagert ist, heist das noch lange nicht, dass man automatisch (gut) objektorientiert programmiert.

fluxy

Hallo,

1.) Das leider war nicht so sehr auf die Fachrichtung bezogen, sondern mehr auf das was ich lerne.

2.) Ich mache auch Java und komme da ziemlich gut zurecht, zumindest bei dem, wozu ich Java brauche. Ich will aber das ganze mal in C++ richtig lernen.

Real

Korbinian schrieb:

Real schrieb:

Java ist optimal für den Anfang was Objektorierung und sauberer Code angeht.

nur weil bei java alles zwanghaft in klassen gelagert ist, heist das noch lange nicht, dass man automatisch (gut) objektorientiert programmiert.

Java ist eben eine komplett Objektorientierte Sprache, das hat den Vorteil, dass man Java-Entwickler am Besten bescheid wissen, was Objektorierung ist.
Bei Exceptions z.B. gibt es die Oberklasse Exception; diese ist in mehreren Unterklassen wie z.B. IndexOutOfBoundsException unterteilt und diese wiederum ist auch in StringIndexOutOfBounds und ArrayIndexOutOfBounds unterteilt (vielleicht auch mehr). Wenn du also gleichzeitig ArrayIndexOutOfBounds- und StringIndexOutOfBoundsExceptions abfangen willst, dann nimmst du deren Oberklasse IndexOutOfBoundsEceptions. Oder wenn du komplett alle Fehler abfangen willst, nimmst du die Oberklasse aller Oberklassen Exception.

Ausserdem vereinfacht Java enorm Objektumwandlungen in allen Objekten, da eben alles ein Objekt ist.
Ich könnte z.B. die Klasse String und deren Methoden ganz einfach überschreiben. Wenn ich z.B. die Methode lenght() erweitern will, dann überschreibe ich sie ganz einfach. Oder wenn ich gewisse Inkompatibilitäten ausgleichen will, dann kann ich auch einfach die Methoden überschreiben und anpassen.

(Bin mir nicht sicher, ob das in C++ auch geht, da ja nicht alles ein Objekt ist; müsst ihr am Besten wissen. (klar, Funktionen überschreiben könnt ihr auch, aber eben nur wo es Klassen gibt.))

Sauberen Code lernt man auch programmieren, da Sicherheitsmängel in Java nicht erlaubt sind.

Liebe Grüße
Real

fluxy

Hmmm vielleicht könnt ihr mir mal bei einem praktischen Beispiel helfen, wenn ihr mir nur mal sagt, wie mein System organisatorisch laufen muss.

Hier mal so ne Art Spezifikation:

Es soll ein Pluginsystem entstehen, welches von einem Manager gesteuert wird. Die Anwendung darf also nur von den Interfaces und dem Manager wissen, sonst von nix. Ziel ist es, dass natürlich die Anwendung Zugriff auf alle Plugins hat, aber weiterhin auch die Plugins Zugriff aufeinander haben, ohne dass sie voneinander abhängig sind. Also die Plugins dürfen nicht voneinander wissen, sie sollen in jeden Fall über einen solchen Manager gehen.

Im formum habe ich ja auch schon folgende Lösungsvorschläge mitbekommen:

1.) Visitor Pattern bzw. double dispatching zur vermeidung von RTTI casts

weiterhin hatte ich vor

2.) Verwendung des Command Design Patterns zur Kommunikation der Plugins über den Pluginmanager (mit ists noch nicht ganz klar aber vielleichts wirds mir ja bald klar)

3.) Heute morgen ist mir klar geworden, ich sollte eventuell Exceptions benutzen, was haltet ihr davon? Geht das überhaupt mit Plugins (wegen der dll) ?

Gruß Sebastian

Glamdring

Aufgaben könnte ich dir stellen, wär zwar alles auf mein Projekt bezogen (ich klau dann deine Designideen :p ). Obwohl sich auch dein Projekt gut anhört (kann ich auch gebruachen). Ansonsten hab ich mit OOP für Dummies gute Erfahrungen gemacht.

mfg

otze

mir kam als ich die GUI der WinAPI zu wrappen began ne gute idee wie man objekte kompletzt voneinander unabhängig machen kann, vielleicht intressierts ja jemanden, oder dich fluxy:

Man könnte vielleicht eine erweiterte version des Messaging system der WinAPI benutzen.
Auch wenn viele eine relativ schlechte meinung über dieses system der WinAPI haben, bin ich einfach nur fasziniert von den möglichkeiten die es bietet, und die es bieten könnte, wenn man es ausbaut.

Objekte sind sogut wie komplett voneinander abgekapselt, sie sind nur durch eine allgemeine verbindung über die messages miteinander verbunden.
diese messages bieten ein enormes potential, so kann zb ein objekt einfach folgende nachricht rumschicken: "ich brauch die datei xyz aus dem archiv abc", diese message wird dann rumgereicht, bis ein ziel gefunden wurde welches die fähigkeiten besitzt,die nachricht zu verarbeiten, und die antwort geht dann direkt zurück an den absender der nachricht. dh ein objekt brauch nichts von seiner umgebung zu wissen, ausser dass es da einen weg gibt anfragen zu schicken und antworten zu erhalten. Das hat zurfolge, dass ein objekt nicht dadurch klassifiziert wird, was für ein interface es besitzt, sondern was für nachrichten es erhalten/verarbeiten/senden kann.

meinungen zu diesem Ansatz? würde es sich lohnen, noch mehr denkarbeit reinzustecken?

Peter I

Hallo Leute,

was für ein Compiller benutzt ihr so bei ILS ???
Borland???
Watcom???

Bei SGD ist es Watcom C++ und Power++
?????
Danke!

interpreter

otze schrieb:

mir kam als ich die GUI der WinAPI zu wrappen began ne gute idee wie man objekte kompletzt voneinander unabhängig machen kann, vielleicht intressierts ja jemanden, oder dich fluxy:

Man könnte vielleicht eine erweiterte version des Messaging system der WinAPI benutzen.
Auch wenn viele eine relativ schlechte meinung über dieses system der WinAPI haben, bin ich einfach nur fasziniert von den möglichkeiten die es bietet, und die es bieten könnte, wenn man es ausbaut.

Objekte sind sogut wie komplett voneinander abgekapselt, sie sind nur durch eine allgemeine verbindung über die messages miteinander verbunden.
diese messages bieten ein enormes potential, so kann zb ein objekt einfach folgende nachricht rumschicken: "ich brauch die datei xyz aus dem archiv abc", diese message wird dann rumgereicht, bis ein ziel gefunden wurde welches die fähigkeiten besitzt,die nachricht zu verarbeiten, und die antwort geht dann direkt zurück an den absender der nachricht. dh ein objekt brauch nichts von seiner umgebung zu wissen, ausser dass es da einen weg gibt anfragen zu schicken und antworten zu erhalten. Das hat zurfolge, dass ein objekt nicht dadurch klassifiziert wird, was für ein interface es besitzt, sondern was für nachrichten es erhalten/verarbeiten/senden kann.

meinungen zu diesem Ansatz? würde es sich lohnen, noch mehr denkarbeit reinzustecken?

Ich glaube nicht, dass das irgend was bringt. Erstens brauchen alle Objekte ja doch eine gemeinsame Schnittstelle, damit sie miteinander kommunizieren können und Zweitens hört sich dieses System der "Message rumreichen" ineffizient an.

Glamdring

@otze: für mich hört sich das interessant an, dass könnte man ja auch mit Hilfe der Chain of Possibility machen.

@interpreter: Warum? Man könnte doch das Objekt, dass für die verarbeitung verantwortlich ist auch per Komposition einbinden (Blackbox-Wiederverwendung). So bleiben alle Objekte unterschiedlich, aber können, üder das "Nachrichtenobjekt" doch gleich behandelt werden.

Erhard Henkes

Das hat zurfolge, dass ein objekt nicht dadurch klassifiziert wird, was für ein interface es besitzt, sondern was für nachrichten es erhalten/verarbeiten/senden kann.

So läuft das doch hier im Forum. Einer schickt eine Nachricht und wartet. Andere Objekte (z.T. auch Subjekte ;)) reagieren auf bestimmte Reizwörter und antworten. Die Antwort sehen hier nur alle Objekte, wenn sie auf die Reizwörter reagieren.

Gibt es ein Programm, das dies simuliert, außer dem biologischen Körper?

otze

@interpreter stimmt, das rumreichen kann ineffizient sein, dafür bietet es aber auch für jedes plugin die maximale Freiheit. Imho war ich gestern mit meinen überlegungen noch nicht weit genug, um das abzuhandeln, ich denk aber, ich hab ne schöne lösung gefunden.
Die schnittstelle ist übrigens schnell gemacht:

class Plugin{
    public:
        virtual Message sendMessage(const Message&)=0;
        virtual Handel getHandel()=0;
        //und vielleicht noch eine function die die möglichen messages
        //enthält, die empfangen/gesendet werden können
        virtual MessageDesc getMessageDesc()=0;
};

meine weiteren überlegungen:

Ich hab das system inzwischen von "plugins only" zu "objekte aller art" ausgeweitet.

Das system des Rumreichen der Messages ist wohl der knackpunkt der angelegenheit:
sollte das system doch zentralisiert sein,könnte man alle objekte dazu anweisen, ihre messages direkt an eine verarbeitungsstelle weiterzureichen, die wiederrum die messages an das korrekte objekt zum verarbeiten sendet.
wenn die verarbeitung geglückt ist, schickt das verarbeitende objekt eine message zurück zur Zentrale die die message dann zum absender der anfrage schickt.
Vorteil: das system ist wirklich einfach, die zentrale verwaltet alles, und die objekte haben einen festen ort an dem sie ihre postgeschäfte abwickeln.
Desweiteren können objekte komplett von der existenz anderer objekte abgeschirmt werden, für das einzelne objekt existiert nur die zentrale.
Und der letzte punkt ist,dass über die plugins sogut wie garnichts bekannt sein muss.

Nachteile: erstmal währen da die beiden weiterleitungsvorgänge zur zentrale hin und von der zentrale weg, was mindestens 2 mal wiederholt wird.
das Hauptproblem ist somit, dass objekte die zur verarbeitung andre objekten post schicken wollen, auch immer über die Zentrale gehen müssen, und wenn man mal von einem "Körperähnlichen" programm ausgeht, können das verdammt viele nachrichten sein, die da über die zentrale laufen. Für kleine projekte ist der aufwand noch vertretbar, zb wenn die einzelnen objekte selber autark sind, und nur "arbeite" und "mach pause" messages brauchen,für große projekte währe der overhead aber gigantisch.
Dieser ansatz entspricht übrigens am meisten dem was ich im letzten post gesagt hab...
hiuer eine einfache schematische zeichnung, o ist objekt, z ist zentrale

O O 0
    \|/
   O-z-O

möglichkeit nr2:
eine abwandlung der letzten möglichkeit: statt einer Zentrale haben wir nun mehrere vernetzte zentralen, die jeweils gruppen von plugins bündeln, was vorallem dort vorteile bringt, wo man mit 2 oder mehreren gruppen von plugins rechnen muss, als beispiel währe das in einem malprogramm einmal die möglichkeit der integration von plugins für verschiedene formen zum zeichen(dreieck viereck kreis ellipse usw), andererseits auch filter wie "gausscher weichzeichner" oder "Harte Kanten".
Der arbeitsaufwand verringert sich durch diese gruppenbildung enorm, da sich messages die zwischen gruppenmitgliedern ausgetauscht werden sollen einen viel kleineren verwaltungsaufwand innerhalb der zentrale benötigen(ich schätze mal dass der algorithmus zum raussuchen eines objekts über die zentrale eine lineare laufzeit hat).Wenn eine message nicht gruppenintern ist, wird sie einfach an die stelle geschickt, die sie evrarbeiten kann.
haben wir ein programm mit 10 objektgruppen, und ein objekt sendet eine nachricht die zu einem objekt in einer andren gruppe gehen soll, so fallens chon 8 andre gruppen mit ihren objekten raus, also auch da wieder eine erhebliche erleichterung.

Natürlich muss die Zentrale nun mehr über das objekt wissen, um es zu einer gruppe zuordnen zu können.
Ansonten is alles so wie in möglichkeit eins.

und wieder eine zeichnung

O\   /O
O-Z-Z-O
O/   \O

3. möglichkeit:
absolut dezentralisiert, das system ist in etwa wie ein lernendes neuronales netzwerk aufgebaut(also rein äußerlich).
die plugins sind erstmal in einem symetrischen system angeordnet(sagen wir mal ein Kreis), und versuchen sich anfangs notdürftig zu behelfen, indem sie einfach eine message an einen nachbar schicken, wenn er die verarbeiten kann(und nur dann) sendet er eine message an den absender ab, die ein ok signalisiert, ansonsten gibt er die nachricht an den nächsten weiter.
Nachrichten haben also in dem system einen "Absender" und das objekt das eine nachricht verarbeiten kann, sendet die nachricht auf dem direkten weg zurück.
Erhält nun das absenderobjekt so eine nachricht von einem andren Objekt, erstellt es eine direkte connection zu diesem objekt. Das nächste mal, wenn das Objekt wieder dieselbe nachricht schicken muss, sendet es die nachricht auf direktem weg zu dem objekt.
Das netzwerk hat sich selbst optimiert.
ok, ein problem krieg ich nicht gebacken: was passiert, wenn eine nachricht nicht (mehr) verarbeitet werden kann? Die nachricht wird ja immerwieder weitergereicht, und kein objekt kann was mit anfangen-das programm ist in einem lock...
vielleicht bieten die neuronalen netzwerke ansich noch mehr möglichkeiten, um mit diesem problem fertig werden zu können, aber dahingehend hab ich keine ahnung^^

vielleicht hat noch jemand von euch dahingehende ansätze, ich find das thema aufjedenfall superintressant

nman

Real schrieb:

Java ist eben eine komplett Objektorientierte Sprache, das hat den Vorteil, dass man Java-Entwickler am Besten bescheid wissen, was Objektorierung ist.

*lol*
Meinst Du Sachen wie das Math-Objekt seien schön und nur weil alles in Objekte reingequetscht wird ist Java ein gutes Beispiel wie OOP aussehen sollte?
Sieh Dir doch mal Ruby an, das ist eine konsquent objektorientierte Programmiersprache!

Bei Exceptions z.B. gibt es die Oberklasse Exception; [...]

Uh, in C++ gibts das auch alles.
Beispiel: std::invalid_argument ist ein std::logic_error und std::logic_error ist eine std::exception.

Ausserdem vereinfacht Java enorm Objektumwandlungen in allen Objekten, da eben alles ein Objekt ist.

Äh ja...

(Bin mir nicht sicher, ob das in C++ auch geht, da ja nicht alles ein Objekt ist; müsst ihr am Besten wissen. (klar, Funktionen überschreiben könnt ihr auch, aber eben nur wo es Klassen gibt.))

Geht auch in C++, das hat nix mit Objekt oder nicht-Objekt zu tun.
Ein std::string hat zb einen Konstruktor der ggf. als Argument ein Stringliteral vom Typ const char* entgegennimmt, darum können wir meist auch damit leben dass "foobar" kein std::string ist.

Sauberen Code lernt man auch programmieren, da Sicherheitsmängel in Java nicht erlaubt sind.

Erklärst Du mir das bitte? (Warum man durch Java sauber programmieren lernt meine ich.)

Surfman

hi!
hast du auch schon visual c .net? meld dich mal per mail...

cu

SirLant

Wenn wir nochmal wer behauptet, dass Java ne super Sprache ist um OOP zu lernen, weil man damit nur OOP programmieren kann, dann poste ich hier mein TicTacToe Spiel, dass ich in Java absolut nicht OO mäßig programmiert habe sondern Prozedural in der Hauptklasse :p

Glamdring

@SirLant: So ists richtig!