Punkt in der Ebene objektorientiert darstellen

Hi,
kann mir jemand sagen wie man einen Punkt in der Ebene objektorientiert darstellen kann ?

In der Übung 2 und 3 haben Sie eine erste Version der Saugroboter-Klasse entworfen. Dabei haben Sie die Position des Saugroboters in der Ebene mit zwei Werten, der Position auf der x-Achse und der Position auf der y-Achse, beschrieben.

Diese unabhängige Behandlung der beiden Werte ist bei näherer Betrachtung nicht objektorientiert. Denn tatsächlich sind ein Wert auf der x-Achse und der y-Achse die Eigenschaften von etwas, das man als „Punkt“ in der Ebene bezeichnet, und das auch objektorientiert modelliert werden kann.

Marthog

class Punkt
{
// ...

    float x;
    float y;
};

TyRoXx

Mehrere Werte zu einem Objekt zusammenzufassen nennt man Aggregation. Für so etwas einfaches lohnt es sich nicht die Bezeichnung "OOP" aus dem Werkzeugkasten zu holen. Auch, wenn der Punkt verlockend nach einem Nagel aussieht.

volkard

TyRoXx schrieb:

Mehrere Werte zu einem Objekt zusammenzufassen nennt man Aggregation. Für so etwas einfaches lohnt es sich nicht die Bezeichnung "OOP" aus dem Werkzeugkasten zu holen. Auch, wenn der Punkt verlockend nach einem Nagel aussieht.

Ähm. Doch.

TyRoXx

volkard schrieb:

Ähm. Doch.

Ähm. Nein. Und jetzt?

EDIT: Ok, es ist "objektorientiert" im Sinne von UML.

Synonym

TyRoXx schrieb:

volkard schrieb:

Ähm. Doch.

Ähm. Nein. Und jetzt?

EDIT: Ok, es ist "objektorientiert" im Sinne von UML.

Es ist "objektorientiert" im Sinne der Objektorietierung. Man fasst in dem Beispiel zwei werte zusammen die ohne einander 'sinnlos' wären. Meiner bescheidenen Meinung nach ist es doch einer der Kerngedanken hinter der OO, wenn ich mich irre dann bitte verbessern..

Skym0sh0

Naja, mir fehlt jetzt noch der Gedanke, dass man Operationen auf den zusammengefassten Daten anbietet. Vielleicht kann man noch über Kapselung nachdenken.

TyRoXx

Synonym schrieb:

Man fasst in dem Beispiel zwei werte zusammen die ohne einander 'sinnlos' wären.

Das nennt man Aggregation. Die ist weder notwendig für OOP, noch hinreichend.

Synonym schrieb:

Meiner bescheidenen Meinung nach ist es doch einer der Kerngedanken hinter der OO, wenn ich mich irre dann bitte verbessern..

Der Kerngedanke von "OOP" ist es, mit Kästchen und Pfeilen die Grenzen zwischen Objekten und Klassen so lange zu verschmieren, bis niemand mehr weiß welches Problem man eigentlich lösen wollte.

Der Kerngedanke von OOP ist es, Daten und Operationen als Einheit zu betrachten. Eine Einheit aus Daten und Operationen nennt man Objekt.
Der Punkt hat gar keine Operationen abgesehen von generiertem POD-Gedöns. Der ist einfach nur ein Aggregat, das man zufällig in C++ mit class definiert. class wird in C++ zufällig auch dafür benutzt Schablonen für Objekte zu definieren. Dass die Syntax in C++ ähnlich ist, impliziert für mich noch nicht, dass Punkt-Instanzen sinnvolle Beispiele für OOP-Objekte sind.

Synonym

TyRoXx schrieb:

Synonym schrieb:

Man fasst in dem Beispiel zwei werte zusammen die ohne einander 'sinnlos' wären.

Das nennt man Aggregation. Die ist weder notwendig für OOP, noch hinreichend.

Synonym schrieb:

Meiner bescheidenen Meinung nach ist es doch einer der Kerngedanken hinter der OO, wenn ich mich irre dann bitte verbessern..

Der Kerngedanke von "OOP" ist es, mit Kästchen und Pfeilen die Grenzen zwischen Objekten und Klassen so lange zu verschmieren, bis niemand mehr weiß welches Problem man eigentlich lösen wollte.

Der Kerngedanke von OOP ist es, Daten und Operationen als Einheit zu betrachten. Eine Einheit aus Daten und Operationen nennt man Objekt.
Der Punkt hat gar keine Operationen abgesehen von generiertem POD-Gedöns. Der ist einfach nur ein Aggregat, das man zufällig in C++ mit class definiert. class wird in C++ zufällig auch dafür benutzt Schablonen für Objekte zu definieren.

aber darum geht es bei der Frage des TO nicht... Er möchte das man ihm zeigt/sagt wie man es in eine Klasse packen würde. Ich lese aus der Übungsaufgabe heraus das man dort ein struct oder wohl eher ein class verwenden soll um diese beiden koordinaten zusammen zu fassen.
Da es sich um eine Übungsaufgabe handelt kann man nicht erwarten das man bei dem bloßen Gedanken des "zusammenfassens von Werten" schon darauf kommt das man zugriffsmethoden schreib, diese Werte kapselt und was auch immer.

Du hast aber recht das es eine Aggregation ist. Ich würde btw dafür aber kein class nehmen sondern ein struct. Dies verdeutlicht meiner Meinung nach das man nicht objektorientiert arbeiten will in diesen fall. Aber das ist subjektiv.

Marthog

Synonym schrieb:

Du hast aber recht das es eine Aggregation ist. Ich würde btw dafür aber kein class nehmen sondern ein struct. Dies verdeutlicht meiner Meinung nach das man nicht objektorientiert arbeiten will in diesen fall. Aber das ist subjektiv.

Ich würde aber den Punkt zumindest bei größeren Aufgaben als Vektor darstellen und dann auch Vektoraddition, Skalarmultiplikation, Abstands- und Längenberechnung, Skalarprodukt, etc. mit anbieten (und damit auch OOP verwenden). Bei kleineren Sachen, gerade wenn man keine Vektorrechnung braucht, ist ein POD-Type (und damit struct) angebracht.

ScottZhang

also wäre es OOP wenn man jetzt noch die entsprechen Methoden (+,-,*, copy, assign usw.) anbieten würde?

Helmut.Jakoby

Ist ein 'Abstrakter Datentyp' nicht OOP?

Columbo

Helmut.Jakoby schrieb:

Ist ein 'Abstrakter Datentyp' nicht OOP?

In C++ ist ein abstrakter Datentyp am ehesten eine abstrake Basisklasse (meinst du das?). Dann ja. Eine Struktur, die lediglich mehrere Werte zusammenfasst, nennt man Aggregat (engl. aggregate) - unterstützt C zum Beispiel OOP? Natürlich nicht.

TyRoXx

Der Punkt ist deswegen ein schlechtes Beispiel für OOP, weil der nichts tut. Er pappt einfach nur zwei Zahlen aneinander ohne diese in eine Beziehung zu setzen. Jede Kombination von int s ergibt einen gültigen Punkt. Deswegen muss und sollte man hier nichts künstlich kapseln.
Oder anders betrachtet: Sein Interface ist bereits seine Implementierung. Er braucht keine nicht-trivialen Operationen, also ist er auch kein nicht-triviales Objekt. Die Punkt-Instanz ist nicht mehr Objekt als es eine einzelne int -Instanz wäre.

Nexus

OOP ist lediglich ein Konzept, ich würde hier nicht zu stark in Java-Mustern denken. Klassen sind für OOP z.B. nicht notwendig. Man kann auch in C objektorientiert programmieren, und so ziemlich jede grössere Bibliothek tut das.

Synonym hat Recht, dass der Grundgedanke von Objektorientierung wortwörtlich darin liegt, in Objekten zu denken, also zusammengehörige Daten und Funktionalität zusammenzufassen. Was zählt ihr zu "Funktionalität"? Konstruktoren? Getter/Setter? Compilergenerierte Konstruktoren?

TyRoXx schrieb:

Die Punkt-Instanz ist nicht mehr Objekt als es eine einzelne int -Instanz wäre.

Eine Frage dazu. Wenn du eine Klasse schreibst, die sich in nahezu allen Situationen wie int verhält, der Anwender also keinen wesentlichen Unterschied zu int selbst sieht: Warum ist das eine ein Objekt und das andere nicht? OOP wäre hier reines Implementierungsdetail.

Columbo

Warum ist das eine ein Objekt und das andere nicht?

Ich nehme an, du meinst hier Objekt im Sinne von OOP und nicht im Sinne des Standards (in dessen Sinne das beides Objekte wären).

Nun, ich würde sagen, für die Klasse müssen ja Memberfunktionen aufgerufen werden, um das Verhalten zu simulieren, während das bei einem Skalar natürlich nicht der Fall ist.

Compilergenerierte Konstruktoren?

Die sind überhaupt erst zu berücksichtigen wenn sie nicht trivial sind.