Frage zu Go und OOP?

Objektorientierung unterstützt Go durch Interfaces und Mixins. Auf Klassen wird bewusst verzichtet.

http://de.wikipedia.org/wiki/Go_(Programmiersprache)

Interfaces und Mixins sind doch kein Ersatz für Klassen und Klassen sind die Grundlagen für die OOP.

Wie kann man also davon sprechen, daß Go eine objektorientierte Sprache wäre?

Bashar

OO schrieb:

Klassen sind die Grundlagen für die OOP.

Nö, Objekte und Nachrichten sind es.

SideWinder

Ich kenne Go nicht, aber Klassen sind nicht wirklich in irgendeiner Definitionn von OOP zu finden. Es heißt ja objektorientierte Programmierung und nicht klassenorientierte Programmierung.

MfG SideWinder

Bashar schrieb:

OO schrieb:

Klassen sind die Grundlagen für die OOP.

Nö, Objekte und Nachrichten sind es.

Ja, aber was ist denn ein Objekt?

Eine Instanz einer Klasse, also ein Objekt mit Attributen und Methoden und das wird eben über die Klassendefinition definiert.

Wie sieht denn ein Objekt aus, daß keine Attribute und Methoden hat?

SideWinder

OO schrieb:

Wie sieht denn ein Objekt aus, daß keine Attribute und Methoden hat?

Attribute und Methoden können doch bspw. auch vollkommen dynamisch erstellt werden, da muss es ja nicht unbedingt ein Template (edit: Prototyp war ein denkbar ungünstiger Begriff...) geben. Da versteifst du dich zu sehr auf stark typisierte Sprachen bzw. Sprachen im Stil von C++/Java/C# die dieses Konzept gewählt haben.

Edit: Sieh dir bspw. mal JavaScript an

MfG SideWinder

Zeus

type Vertex struct {
	X, Y float64
}

func [u](v *Vertex)[/u] Abs() float64 { // Der Empfänger
	return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

func main() {
	v := &Vertex{3, 4}
	fmt.Println([u]v.Abs()[/u])  // Methoden Aufruf von Vertex.Abs
}

Sieht anders aus als eine Klassen, verhält sich gleich, Go ist statisch. Ähnlich Konzept: C# Extension Method.

SideWinder schrieb:

OO schrieb:

Wie sieht denn ein Objekt aus, daß keine Attribute und Methoden hat?

Attribute und Methoden können doch bspw. auch vollkommen dynamisch erstellt werden, da muss es ja nicht unbedingt ein Template (edit: Prototyp war ein denkbar ungünstiger Begriff...) geben. Da versteifst du dich zu sehr auf stark typisierte Sprachen bzw. Sprachen im Stil von C++/Java/C# die dieses Konzept gewählt haben.

Edit: Sieh dir bspw. mal JavaScript an

MfG SideWinder

Zeig mir mal da anhand eines Beispielcodes wie du das meinst.

Für mich ist die Vorstellung eines Objekts ganz klar an Attributen und Methoden gekoppelt.

Habe ich nur Attribute die etwas komplexes definieren, wie z.B. in C, dann würde ich das ganze Struct nennen und nicht unbedingt Objekt, auch wenn man im C Kontext dann vielleicht von einem Objekt sprechen würde, so ist es letzten endes halt doch nur ein komplexerer Datentyp realisiert mit einem Struct.
Aber streng genommen sind zu einem Struct eben keine Methoden gekoppelt.

Zeus schrieb:

type Vertex struct {
	X, Y float64
}

func [u](v *Vertex)[/u] Abs() float64 { // Der Empfänger
	return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

func main() {
	v := &Vertex{3, 4}
	fmt.Println([u]v.Abs()[/u])  // Methoden Aufruf von Vertex.Abs
}
Sieht anders aus als eine Klassen, verhält sich gleich, Go ist statisch. Ähnlich Konzept: C# Extension Method.

Okay, verstehe.

Aber was soll da beim Programmieren der Vorteil sein, wenn die Funktionen bzw. Mthoden lose von den Attributen im Code herumschwirren?

Ganz besonders im Hinsicht auf die Wartbarkeit von Software.

Bei Klassen habe ich alles (Objekte & Methoden) schön zusammen an einem Ort.

Bei dem obigen Beispielcode ist aber alles lose getrennt.
Sprich, als Progger muß ich mir die Funktionen dann zusammensuchen um überhaupt rauszufinden, welche Funktionen ich für mein Objekt schon habe und verwenden kann.

Vom Standpunkt der objektorientierten Softwareentwicklung muss das doch ein Rückschritt sein?

Shade Of Mine

OO schrieb:

Aber was soll da beim Programmieren der Vorteil sein, wenn die Funktionen bzw. Mthoden lose von den Attributen im Code herumschwirren?

http://de.wikipedia.org/wiki/Mixin

Mixins gibt es in vielen Ausführungen. Prinzipiell ist das Problem folgendes:
Warum willst du alles in einer Klasse haben? In C++ ist es zB so, dass du teilweise Funktionen in der Klasse hast und teilweise ausserhalb. Deshalb wurde zB ja begin(v) statt v.begin() eingeführt weil es einfach praktischer ist die Sachen eben nicht in der Klasse zu haben.

Weil dann nämlich plötzlich Überladung wieder greift und man generalisierte Varianten anbieten kann. Schau dir zB std::swap an.

Mixins sind in vielen Sprachen schon Standard geworden. C#, Go, Objective-C, Ruby,...

Es gibt aber viele Ansätze. zB gibt es Prototype basierte Sprachen wie zB JavaScript wo du ein Objekt hast zu dem du jederzeit neue Funktionalität hinzufügen kannst.

Schau dir einfach mal JavaScript an. Das ist eine interessante Sprache die OOP komplett anders versteht als man es aus der Java Welt kennt. Und es gibt massig Dokumentation dazu.

PS:

Sprich, als Progger muß ich mir die Funktionen dann zusammensuchen um überhaupt rauszufinden, welche Funktionen ich für mein Objekt schon habe und verwenden kann.

Die selbe Argumentation (ohne ein Wort zu ändern) kann man auch gegen Funktionen verwenden.

Das sollte dir zu denken geben. Denn Funktionen sind doch in der Tat recht praktisch, oder?

Zeus

Nein ist es nicht, der Verbund ist nicht mehr die Klasse sondern das Module (die Go Datei). Wenn du die Macher der Sprachen fragen würdest, würden sie dir Antworten, dass du ein Haufen von Zeit verschwendest, dass du Strukturen aufbauen muss, damit du hinterher herauszufinden, dass sie nicht stimmen, um dann Neue aufzubauen, never ending cyling.