Wofür braucht man Klassen?

[Rüdiger]

Hallo Leute,

ich weiß zwar, wie man sie schreibt, aber wann man sie genau einsetzen sollte, habe ich noch nicht ganz verstanden.
Könnte mir freundlicherweise jemand ein kurzes, einfaches Beispiel nennen, wo man unbedingt eine Klasse braucht und z.B. eine Funktion nicht ausreicht?

[ChrisB]

Hi,

ich weiß zwar, wie man sie schreibt, aber wann man sie genau einsetzen sollte, habe ich noch nicht ganz verstanden.
Könnte mir freundlicherweise jemand ein kurzes, einfaches Beispiel nennen, wo man unbedingt eine Klasse braucht und z.B. eine Funktion nicht ausreicht?

Objektorientierte Programmierung ist ein anderes Paradigma als bspw. funktionale Programmierung. Es geht nicht darum, ob man das unbedingt „braucht“, sondern welche Vorteile das hinsichtlich der Organisation des Codes und der Kapselung von Daten hat.

Anhand eines Kurzbeispiels ist das allerdings nicht wirklich einfach zu erklären. Mein Tipp lautet: Selber Erfahrungen damit sammeln.

MfG ChrisB

[Cheatah]

Hi,

Objektorientierte Programmierung ist ein anderes Paradigma als bspw. funktionale Programmierung. Es geht nicht darum, ob man das unbedingt „braucht“, sondern welche Vorteile das hinsichtlich der Organisation des Codes und der Kapselung von Daten hat.

Anhand eines Kurzbeispiels ist das allerdings nicht wirklich einfach zu erklären.

richtig. Ich versuche es mit einer Analogie: Funktionales kontra objektorientiertes Programmieren ist wie zu Fuß gehen kontra mit dem Auto fahren. Das Gehen zu Fuß lernt man (i.d.R.) sehr viel früher und kann (ebenfalls i.d.R.) recht gut damit umgehen; Autofahren ist zunächst(!) ungleich umständlicher und erfordert viel Einlernzeit und -arbeit. Und wie bei allen Analogien zu computerbezogenen Themen ist auch hier der Vorteil (sowie die Situationen, in denen mehr Nachteile bestehen) um einiges klarer ersichtlich.

Ich möchte jedenfalls nicht von Karlsruhe nach Berlin zu Fuß gehen ... wohl aber zum Supermarkt um die Ecke, es sei denn ich gedenke, schwere oder sperrige Dinge zu kaufen.

Mein Tipp lautet: Selber Erfahrungen damit sammeln.

Jupp.

Cheatah

[Encoder]

Wenn du Daten halten willst, die auf irgendeine Art zusammengehören, kannst du eine Klasse nehmen. Zum Beispiel Personendaten. Wenn die Klasse dann noch Methoden hat, wie etwa anhand des Geburtsdatums das Alter ausrechnen oder so, dann hast du ein Beispiel für eine Kapselung von Daten und Funktionen (die werden hier Methode genannt).

Wenn ein Projekt mal größer wird bist du um alles froh, was dir aus sagen wir mal 500 Methoden vielleicht 50 Klassen mit aussagekräftigem Namen und nur jeweils 10 Methoden macht.

[Gugu]

Könnte mir freundlicherweise jemand ein kurzes, einfaches Beispiel nennen, wo man unbedingt eine Klasse braucht und z.B. eine Funktion nicht ausreicht?

Du kannst mit beiden Programmierarten so ziemlich alles erledigen. Der wesentliche Unterschied ist, dass objektorientierte Programmierung vieles (nicht alles) klarer und aufgeräumter strukturiert.

Ganz banales Beispiel: Um eine Variable als Text darzustellen, kannst du

… einzelne Funktionen à la feld_als_text(), nummer_als_text(), datum_als_text() schreiben (aber kein text_als_text(), denn das wäre ja überflüssig).

… eine Klasse Variable mit der Methode text() erzeugen und davon für die einzelnen Datentypen Unterklassen (Feld, Nummer, Datum, Text) ableiten, die ihrerseits die Methode text() überschreiben.

In ersterem Fall musst du bei jeder Variablen selbst die richtige Funktion auswählen. Du musst in die Anleitung schauen, ob es eine gibt und wie sie heißt (was insbesondere bei PHP lustig ist, weil der Name mal dem Schema feld_als_text() folgt, anderswo aber nummeralstext() oder VerwandleDatumInText()).
Brauchst du obendrein in einem Projekt eine spezielle Umwandlung einer Nummer in einen Text, kannst du die Funktion nicht einfach nummer_als_text() benennen, denn dieser Name ist ja bereits vergeben.

Im zweiten Fall kannst du einfach variable.text() aufrufen, egal, welchen Datentyp du gerade vor dir hast (denn sie sind ja alle Unterklassen von Variable), und der Funktionsname text() wäre auch noch frei.

Das ist so natürlich alles etwas an den Haaren herbeigezogen, trifft aber letztlich den Kern der Sache.

[Klawischnigg]

Hi there,

ich weiß zwar, wie man sie schreibt, aber wann man sie genau einsetzen sollte, habe ich noch nicht ganz verstanden.

In PHP braucht man ohnehin keine Klassen. Nachdem Objekte einen Seitenaufruf nicht überleben, ist "objektorientierte Programmierung" in PHP afaik kompletter Schwachsinn...

[Sven Rautenberg]

Moin!

ich weiß zwar, wie man sie schreibt, aber wann man sie genau einsetzen sollte, habe ich noch nicht ganz verstanden.

In PHP braucht man ohnehin keine Klassen. Nachdem Objekte einen Seitenaufruf nicht überleben, ist "objektorientierte Programmierung" in PHP afaik kompletter Schwachsinn...

Dann ist dein Wissensstand in PHP nicht sehr "far".

Objektorientiert zu arbeiten hat nichts mit irgendeiner Lebensdauer von Objekten zu tun. Dasselbe könnte man ja auch gegen Funktionen einwenden - die leben auch nicht länger, als den einen Seitenaufruf, warum also Funktionen einsetzen?

Programmierst du objektorientiert? In welcher Sprache?

- Sven Rautenberg

[Klawischnigg]

Hi there,

Dann ist dein Wissensstand in PHP nicht sehr "far".

Das mag sein, ich kann jedenfalls sehr gut davon leben.

Objektorientiert zu arbeiten hat nichts mit irgendeiner Lebensdauer von Objekten zu tun.

Naja, zumindest mit dem Geltungsbereich. Variable respektive Werte kann ich ja übergeben, Objekte eben nicht.

Dasselbe könnte man ja auch gegen Funktionen einwenden - die leben auch nicht länger, als den einen Seitenaufruf, warum also Funktionen einsetzen?

Funktionen ändern aber nicht ihre Eigenschaften und können über Libraries in jede Seite eingebunden werden.

Programmierst du objektorientiert? In welcher Sprache?

Wenn dann nur Javascript...

[hotti]

moin,

Naja, zumindest mit dem Geltungsbereich. Variable respektive Werte kann ich ja übergeben, Objekte eben nicht.

Wie, Objekte nicht an Subfunktionen übergeben? Da bin ich wohl ein Zauberer, ich mach das nämlich nur noch so ;-)

Meine Objekte kann ich sogar in Dateien speichern und per HTTP durch die Welt schicken.

Programmierst du objektorientiert? In welcher Sprache?

Wenn dann nur Javascript...

So richtig interessant wird es, wenn Objekte zwischen JS und serverseitigen Prozessen ausgetauscht werden sollen. Das Zauberwort heißt "Serialize", zu diesem Thema habe ich ein Handbuch geschrieben, Du findest es auf meiner Seite.

Hotti

[Klawischnigg]

Hi there,

Wie, Objekte nicht an Subfunktionen übergeben?

Subfunktionen? Es ging um die Übergabe von Objekten bei einem Seitenaufruf per http.

Meine Objekte kann ich sogar in Dateien speichern und per HTTP durch die Welt schicken.

Natürlich geht es "irgendwie". Aber für mich ist das nicht im Sinne von objektorientierem Programmieren, wenn ich meine Objekte ständig auseinandernehmen und wieder zusammensetzen muss. Einer der Vorteile von OOP ist ja gerade der Umstand, daß ich mich darum eben NICHT mehr kümmern muss.

So richtig interessant wird es, wenn Objekte zwischen JS und serverseitigen Prozessen ausgetauscht werden sollen. Das Zauberwort heißt "Serialize", zu diesem Thema habe ich ein Handbuch geschrieben, Du findest es auf meiner Seite.

siehe oben...

[Bademeister]

Hi Klawischnigg.

Subfunktionen? Es ging um die Übergabe von Objekten bei einem Seitenaufruf per http.

Du kannst Objekte bei einem Seitenaufruf per http genauso uebergeben wie alle anderen Variablen: gar nicht. Du kannst aber all deren Information bei einem Seitenaufruf per http ganauso uebergeben wie die aller anderen Variablen: als Parameter in Form eines Strings (ganz einfach zu erzeugen etwa mit serialize). Mit Einschraenkungen im Hinblick auf Referenzen, aber die hast Du bei Arrays auch.

Viele Gruesse,
der Bademeister

[Sven Rautenberg]

Moin!

Wie, Objekte nicht an Subfunktionen übergeben?

Subfunktionen? Es ging um die Übergabe von Objekten bei einem Seitenaufruf per http.

Es ging nirgends um die Übergabe von Objekten.

Meine Objekte kann ich sogar in Dateien speichern und per HTTP durch die Welt schicken.

Natürlich geht es "irgendwie". Aber für mich ist das nicht im Sinne von objektorientierem Programmieren, wenn ich meine Objekte ständig auseinandernehmen und wieder zusammensetzen muss. Einer der Vorteile von OOP ist ja gerade der Umstand, daß ich mich darum eben NICHT mehr kümmern muss.

Objektorientiertes Programmieren separiert und gruppiert Funktionen und Daten gleichartiger Zuständigkeit und grenzt diese gegenüber anderen Objekten ab, indem ein Objekt lediglich ein festgelegtes Interface für den Zugriff anbietet.

Wie lange so ein Objekt lebt, ist dabei ziemlich irrelevant. Objektorientierung hat seinen Hauptvorteil nicht in der Langlebigkeit der Objekte, sondern in der vernüftigen Programmierstruktur - wenn man es richtig macht. Wenn man es falsch macht, erzeugt Objektorientierung einfach nur eine zusätzliche Schicht Aufblähung und Performancebremse.

- Sven Rautenberg

[Der Martin]

Hallo,

[Objektorientierung] Wenn man es falsch macht, erzeugt Objektorientierung einfach nur eine zusätzliche Schicht Aufblähung und Performancebremse.

ah, dann habe ich wohl bisher nur viele falsche Approaches gesehen, aber noch keinen richtigen.

Ciao,
 Martin

[hotti]

Moin,

[Objektorientierung] Wenn man es falsch macht, erzeugt Objektorientierung einfach nur eine zusätzliche Schicht Aufblähung und Performancebremse.

ah, dann habe ich wohl bisher nur viele falsche Approaches gesehen, aber noch keinen richtigen.

Das geht mir irgendwie genauso ;-)

Z.B. wurden in unseren Schulungen die Schwerpunkte der OOP gelegt auf Vererbung und Überlagerung von Operatoren. Dabei sind das gerade diejenigen Dinge auf die es gar nicht so ankommt in der Praxis.

Die Musik spielt vielmehr hier:
    *  einheitliche Prozesse,
    * klar definierte Schnittstellen,
    * Scalierbarkeit,
    * überschaubarer Code, Transparenz.

Transparenz und klar abgegrenzte abstract Layer sind beste Voraussetzungen für Teamarbeit. Mitarbeiter werden ersetzbar.

Hottü

[Rüdiger]

Vielen Dank euch allen.
Werde mir jetzt alles mal in Ruhe durchlesen und demnächst häufiger Klassen einsetzen.

[hotti]

hi,

Werde mir jetzt alles mal in Ruhe durchlesen und demnächst häufiger Klassen einsetzen.

Gute Idee!! Wie wärs mit Class::main so zum Beginnen....

Hotti

[Rüdiger]

:-P

Rüdi

[hotti]

:-P

Genau ;-)

Objekte machen Einiges einfacher, auch eine nachträgliche Ver-Ajax-ung. Also ich habe zur Ausgabe ein sog. Superobjekt, das ist die Seite selbst, die so Eigenschaften hat wie title, descr usw.

Dann verwurste ich Benutzereingaben neuerdings auch zu einem Objekt, notwendige Prüfungen finden da z.B. in der new()-Funktion statt. Hier wird entschieden, ob das Objekt überhaupt erstellt werden soll und ggf. werden Hinweise eingebaut. Bei einem fatalError, der zu einem Abbruch führt, werden meine Fehlermeldungen in das Superobjekt eingebaut und eine entsprechende Seite ausgegeben.

Ein aus einer Benutzereingabe resultierendes Objekt ist z.B. eine Nachricht für ein Forum oder eine Mail aus dem Feedbackformular. Es gibt durchaus Klassen, die ich nur für eine Anwendung speziell erstelle, schön ists natürlich, wenn eine solche Klasse auch anderweitig in weiteren Scripten Gebrauch finden kann, in solchen Fällen wird der Code in eine extra Datei, ein Modul ausgelagert.

Meine Webanwendungen sind wie üblich parametergesteuert, dafür sorgt eine Kontrollstruktur. Nach einer Benutzereingabe wird über das Superobjekt eine neue Seite ausgegeben, das Objekt aus dem Input ist darin eingebaut. Bei Ajax wird nicht das Superobjekt geladen, sondern nur noch das Objekt, was aus dem Userinput resultiert.

Hotti :-P(ipe smoking)