Ja, das passt zu den sinnlos (?) statischen Funktionen, die Klassen im Grunde nur für Namespacing nutzen.
Math.random könnte völlig problemlos auch
math_random heißen (jedenfalls, wenn es Funktionen gäbe).
Java hat übrigens Objektentsprechungen für ich glaube jeden primitiven Datentyp (manchmal nützlich für Typehinting). Ich weiß allerdings aus dem Kopf nicht, ob sowas möglich ist:
Code:
Integer n = new Integer();
n.randomize();
Da ergibt es aber womöglich dann doch mehr Sinn, etwas wie
Math.random als Factory aufzufassen (klingt etwas schief), die Integer-Objekte erzeugt, statt jede denkbare (etwa mathematische) Methode an eine Integer-Klasse zu heften.
Na ja, andererseits sind primitive Datentypen für mich nicht wirklich ein Grund, Java nicht als objektorientierte Sprache zu bezeichnen, aber das mag kontextbezogene Definitionssache sein.
* * *
Um mal den Bogen zum Thread zu kriegen: Hier ging es um die Abgrenzung zu prozeduraler Programmierung. Die ist in Java definitiv gegeben, da es glaube ich nicht möglich ist, Funktionen oder Prozeduren zu definieren, sondern nur (Klassen-)Methoden.
Der Sinn von Namespaces ist es, Namenskonflikten zu vermeiden.
Zum Thema "Wieso OOP?"
habe ich zufällig kürzlich auf php.de was geschrieben, das ich mal stumpf kopiere:
Funktionen sind natürlich nicht "per se" schlecht (stating the obvious, eh? ;)). OOP bringt allerdings viele Vorteile mit sich, die vor allem in umfangreicheren Projekten zum Tragen kommen.
Ich habe dazu leider keine gute Quelle griffbereit und möchte nicht mit "Buzzwords" um mich werfen, ohne sie zu erklären. Vielleicht so viel: OOP gruppiert Funktionalität in logischen Einheiten. Beim Einsatz muss (oder besser: darf) ich mich als Programmierer dann jeweils auf diejenige Funktionalität konzentrieren, die der Kontext hergibt. Ein Objekt bietet nur eine überschaubare Anzahl an Methoden an. Bei einem prozeduralen Programmierstil könnte ich theoretisch zu jedem Zeitpunkt jede Funktion mit jedem Argument aufrufen. Das wäre vor allem bei unbekanntem Code nur sehr schwer zu durchblicken. Versuche ich das bei OOP, wirft PHP automatisch aufschlussreiche Fehler (zum Beispiel bei falschen Methodenaufrufen oder falschen Objekttypen als Parametern). OOP verringert also üblicherweise durch diverse Hilfestellungen und Vorschriften die Komplexität, die der Programmierer managen muss.
Das führt zu einer Reihe an günstigen Nebeneffekten wie etwa der Vereinfachung von Teamarbeit oder der besseren Wiederverwendbarkeit von Bestandteilen eines Projekts, weil sich Abhängigkeiten wesentlich einfacher erkennen lassen, als wenn potentiell an jedem Punkt der Anwendung jede Funktion aufgerufen werden könnte.
Viele dieser Vorteile lassen sich bei rein prozeduraler Programmierung nur durch ganz extreme Disziplin (das meine ich nicht als Floskel ;)) und die Einhaltung projektspezifischer (nicht wie bei OOP allgemein standardisierter) Konventionen erreichen.
Tendentiell gilt es abzuwägen. Bei einem Umfang von "einigen Funktionen" wird sich niemand beschweren, dass der Code nicht zu überblicken ist. Aber je länger der Code wird und je weniger diszipliniert bei der Anordnung und Benennung und dem Einsatz von Funktionen vorgegangen wird, desto eher wirst du in Erklärungsnöte geraten, wenn du nicht auf OOP setzt.
Ich persönlich arbeite bei Produktionscode nahezu immer rein objektorientiert, für simple Codebeispiele oder schnell zusammengehackte Dinge halte ich mich dagegen oft an einfache Funktionen, da es in diesen Fällen oftmals keinen Sinn ergibt, Funktionalität in ein größeres Ganzes einsortieren zu wollen. Solche Entscheidungen sind aber auch subjektive Erfahrungssache.
PS: Ich bin weitgehend überzeugt davon, dass sehr gute Programmierer (wiederum keine Floskel) auch große Projekte prozedural programmieren können, ohne Nachteile zu erfahren. Aber generell empfehlen würde ich es nicht.
* * *
T!P-TOP schrieb:
Aber einerseits wäre das doch im Sinne von UML falsch, wenn ich da jetzt auf einmal Methoden von einer Login Klasse für die Registrierung benutze!?
Aber nun dutzende Methoden in eine Klasse zu stecken mit der ich alle Userfunktionen abdecke wäre ja auch blöd, weil das würd ja die Ladezeit enorm erhöhen!?
Ladezeit ist an der Stelle kein Argument, sondern einzig und allein die logische Unterteilung zählt.
Wenn du keinen Anfang findest, würde ich auch empfehlen, dir mal MVC anzusehen beziehungsweise deine Anwendung anhand von Gruppierungen möglicher Aktionen durchzuplanen.
Für ein Nachrichtensystem könntest du zum Beispiel die folgenden Aktionen definieren:
Code:
list - Zeige alle Nachrichten an
show - Zeige eine bestimmte Nachricht an
create - Erstelle eine neue Nachricht
delete - Lösche eine Nachricht
Die müssen nun irgendwie über URLs aufgerufen werden können, etwa zusammengefasst unter einem "messages"-Pfad:
Code:
http://example.org/messages/list
http://example.org/messages/show
http://example.org/messages/create
http://example.org/messages/delete
Das wäre nach MVC nun ein Controller "Messages", der über die Methoden list, show, create und delete verfügt.
Das wäre der Grundgedanke.
Edit: Ein gutes Tutorial zum Zend Framework:
-
http://akrabat.com/zend-framework-tutorial/
Das mag aber alles ein wenig zu übertrieben sein für den Anfang. Na ja, angucken schadet nicht.
