OOP?

[Gast]

Könnt ihr einem absoluten N00b mal erklären, was Objektorientierte Programmierung ist? Wäre euch wirklich sehr verbunden.

Grüße

Peter

[Stone2001]

Original geschrieben von Gast
Könnt ihr einem absoluten N00b mal erklären, was Objektorientierte Programmierung ist? Wäre euch wirklich sehr verbunden.

Grüße

Peter
hmm, im Prinzip gibt es vier Klassen von Programmiersprachen:
- funktionale (applikative) Programmiersprachen (z.B. Haskell oder Gofer)
- logische (deklarative) Programmiersprachen (z.B. Prolog)
- imperative (prodezuale) Programmiersprachen (z.B. Pascal, C)
- objektorientierte Programmiersprachen (z.B. SIMULA 67, SMALLTALK 80, C++, Java)

OK, man kann mit viel Aufwand auch mit einer imperativen Sprache Objektorientiert programmieren, aber... .

Das Grundobjekt der OOP-Sprachen ist die Klasse. Sie enthält Variablen und Methoden, die auf diesen Variablen arbeiten.
Die Klassen können sich mit Hilfe von Botschaften unterhalten oder sich gegenseitig aufrufen. Auch kann eine Klasse Sub-Klasse einer Klasse sein. Sie erbt dann (fast) alle Methoden und Variablen der Super-Klasse, d.h. kann diese Methoden nutzen.

OOP basiert darauf das man versucht, das Problem das man hat, mit Hilfe dieser Objekt zu modellieren und dann zu lösen. (Aber da fangen dann die Probleme des Objektorientierten Entwurfs an: Was ist eine Klasse, was nicht? ... )

[grakaman]

Für einen Anfänger besticht die OOP hauptsächlich durch chatty Interfaces anstatt von chunky Interfaces, Bsp:

Alter Weg:

public void CreateCustomer(FirstName, LastName, Address, State, Phone)
{
// mache etwas
}

Bei OOP benutzt man eher den Weg:

Customer cust = new Customer();
cust.FirstName = "Hans";
cust.LastName = "Meier";
...
cust.CreateCustomer();

oder um die Daten abzufragen, z.B.:

Customer cust = new Customer();
cust.LoadByCustomerID(id);
Console.WriteLine("Hallo {0}", cust.FirstName);

So sollte man das zumindest bei OOP machen, ausser vielleicht bei Remote Objekten, um unnötige Roundtrips zu vermeiden (ausser man macht viele kleine Objekte stateless).
In den obigen Bsp. würde man natürlich auch nicht die ganze Logik implementieren, sondern für eventuelle Datenbankzugriffe extra entsprechende Objekte verwenden, um verschiedene Aufgaben soweit wie möglich zu kapseln. Damit erreichst du eine viel höhere Flexibilität und weniger Fehleranfälligkeit. Ansonsten hat der Vorredner ja schon das Hauptsichtwort gesagt. Klassen sind das A und O, worum sich alles dreht.

MfG

[HellHorse]

Original geschrieben von Stone2001
....
Das Grundobjekt der OOP-Sprachen ist die Klasse
...
Nicht zwangsläufig. Siehe prototypenbasierende Programmiersprachen.
Klassen können Objekte sein, müssen aber nicht.

[Gast]

Original geschrieben von Stone2001
- funktionale (applikative) Programmiersprachen (z.B. Haskell oder Gofer)
- logische (deklarative) Programmiersprachen (z.B. Prolog)was sind die Vorteile von denen?

[MadMan2k]

JavaScript ist prozedural und Delphi OO, gell?

[Gast]

Selbst JavaScript unterstützt objektorientierte Programmierung.

JavaScript oder Sprachen wie C++ und Delphi würde ich aber nicht als objektorientierte Programmiersprachen bezeichnen.

Es gibt Sprachen, die versuchen rein funktional oder objektorientiert (Smalltalk - sogar Schleifen sind objektorientiert gelöst) zu sein, in einer Sprache wie C++ hat man aber die Wahl - das typische C++ Programm ist eine Kombination aus imperativer, funktionaler und objektorientierter Programmierung.

Aber alles Definitionssache, vielleicht hilft allerdings meine Definition beim Verständnis ;)

[Darkstar]

Eigentlich ist Delphi eine Entwicklungsumgebung und Object Pascal die benutzte Sprache. Aber ich will mal nicht so kleinlich sein, da selbst bei Borland die Unterschiede ziemlich stark verwischen. :bäh:

[HellHorse]

Original geschrieben von MadMan2k
JavaScript ist prozedural ...
JavaScript ist sogar prototypenbasiert.

[HellHorse]

Original geschrieben von grakaman
...
Bei OOP benutzt man eher den Weg:

Customer cust = new Customer();
cust.FirstName = "Hans";
cust.LastName = "Meier";
...
So sollte man das zumindest bei OOP machen
...

Nö, eigentlich sollte man encapsulation verwenden.

[Demirug]

Original geschrieben von HellHorse
Nö, eigentlich sollte man encapsulation verwenden.

Und wer sagt dir das dies hier nicht gemacht wurde?

Einige Sprachen erlauben es ja Properties mit set und get Methode zu benutzen.

[Trap]

Um mal noch einen unverständlichen Fachbegriff einzubringen:
Bjarne Stroustrup: My rule of thumb is that you should have a real class with an interface and a hidden representation if and only if you can consider an invariant for the class.
http://www.artima.com/intv/goldilocks3.html

Einige Sprachen erlauben es ja Properties mit set und get Methode zu benutzen.Stimmt, das ist die einzige sinnvolle Neuerung von C# ;)

[Xmas]

Original geschrieben von grakaman
Für einen Anfänger besticht die OOP hauptsächlich durch chatty Interfaces anstatt von chunky Interfaces, Bsp:

Alter Weg:

public void CreateCustomer(FirstName, LastName, Address, State, Phone)
{
// mache etwas
}

Bei OOP benutzt man eher den Weg:

Customer cust = new Customer();
cust.FirstName = "Hans";
cust.LastName = "Meier";
...
cust.CreateCustomer();
Das Schlüsselwort ist hier ganz klar "eher", denn das ist kein integraler Bestandteil der OOP, sondern eher persönliche (und auch Sprach-)Präferenz.