:: ClanSphere :: Free OpenSource Clan CMS :: - Forum

Antworten: 44

Seite < 1 [2] 3 >

reVerB
Thread-Ersteller

Geekboy

Beiträge: 1237

# Antwort: 21 - 04.07.2011 um 21:15 Uhr

Sorry !! Aber so langsam kann ich das auch nicht mehr nachvollziehen. Es ist also böse, Hilfsklassen mit Hilfsmethoden anzuwenden, von denen die Klassen, die es benötigen erben. Statt dessen kann ich da ja dann nur eines machen. Ich kann die Hilfsklassen als statische Klassen anlegen. Etwas anderes macht daher auch kein Sinn. Denn ich werde ein Teufel tun und die ganze Zeit immer mehr Instanzen der Hilfsklassen erzeugen lassen, wenn ich sie als normale Klassen anlege. Oder ich lege eben Hilfsfunktionen an. Denn ich wollte sowieso ausschließlich in den Klassen Prozedural arbeiten, um den Overhead zu verringern.

Inaktiv

SCHIRI

Weltmeister

Herkunft: Hamburg
Beiträge: 5299

# Antwort: 22 - 04.07.2011 um 21:48 Uhr

Was für Hilfsklassen? Also statische Klassen sind eine ganz schlechte Idee.

Welchen konkreten Vorteil versprichst du dir davon, dass Crypt von Security erbt? Welche Methoden soll denn die Security-klasse haben? und welche soll die Crypt-Klasse haben.
Mir kommt es grad so vor, als wenn du denkst, dass die Methoden, die du in Crypt-Definierst dann in Security zu Verfügung stehen - das ist nicht so.

Wenn du sowas machst:

class Security {}

class Crypt extends Security {
public function ecnrypt($text) {
return md5($text);
}
}

Dann geht das hier NICHT:

$security = new Security();
$security->crypt('bla');

Da ist das Schlüsselwort "extends" vllt etwas irreführend, aber so rum funktioniert funktioniert das nicht mit der Vererbung.
Also wofür die Security-Klasse?

Wenn du etwas verschlüsseln willst, macht man es üblicher weise wirklich so:

class Encrypter {
public function encrypt($text) {
// ....
}

public function decrypt($text) {
// ...
}
}

// an der stelle von etwas Verschlüsselt werden soll:

$encrypter = new Encryper();
$result = $encrypter->encrypt('my secret');

Wenn du an 40 stellen in der Anwendung etwas verschlüsseln willst, ist es tatsächlich unpraktisch 40 Instanzen zu erzeugen.
Dafür würdest du dann wieder in der ConfigRegistry (von der du nur eine globale Instanz erzeugst, entweder als Singleton oder du reichst die Registry als Parameter durch die ganze Anwendung durch)

$register->register('encrypter', new Encrypter());

So funktioniert das nunmal in der objektorientierten Programmierung. Wie der Name schon sagt, geht es darum, mit Objekten zu arbeiten und nicht mit Klassen. Der Vorteil den du gewinnst, ist es, dass du den Encrypter (also das Objekt) austauschen kannst, indem du die obere Zeile z.B. damit ersetzt:

$register->register('encrypter', new MySepcialEncrypter());

Einen solchen Aufruf:

Encrypter::encrypt()

kannst du nicht so einfach austauschen. Spätestens wenn du noch einen Encrypt-Key als Config-Paramter angeben willst:

$register->register('encrypter', new Encrypter('my secret key'));

geht das nicht mehr, weil du dann nur noch einen globalen Key setzen könntest:

Encrypter::setKey('mySecretKey');

aber dann gezwungen bist, den auch bei jeder Verschlüsselung zu benutzen. sowas geht nicht mehr:

$encrypter_in_user_modul = new Encrypter('my user encrypt key');
$other_encrypter = new Encrypter('another key');

Einfach weil der Variablenscope einer Klasse eine solche Differenzierung nicht hergibt.

Was mit statischen Methoden auch nicht geht ist das Wrappen von Objekten:

$register->register('encrypter', new EncryptionDecorator(new Encrypter('my secret key')));

--------------------------------------

Ich hatte ja zuanfang schon gesagt, dass die ganze Objektorientierung schnell komplex wird. Einiges davon hängt auch mit dem statischen Klassenmodel von Php zusammen. In anderen Sprachen wie Ruby oder Python (und gewissermaßen Javascript) sind Klassen selbst auch Objekte. Da sieht das ganze noch einen Tick anders aus. Aber in Php, Java und ähnlichen Sprachen bringt das Benutzen von statischen Methoden als Alternative zu Instanz-Methoden nur Nachteile oder ist gar nicht möglich.

Kurz: Wenn du statische Methoden benutzt ist das nicht objektorientiert und du musst zumindest an der Stelle erst gar keine Klasse benutzen.

------------------
www.laszlokorte.de

Inaktiv

reVerB
Thread-Ersteller

Geekboy

Beiträge: 1237

# Antwort: 23 - 04.07.2011 um 22:08 Uhr

Also mein Plan war es, das folgendermaßen zu machen:

abstract class security {
protected setting1;
protected setting2;
protected setting3;

protected function ladeSettings(){ // mach irgendwas }
protected function speichereSettings(){ // mach irgendwas }
protected function hilfsfunktionX(){ // mach irgendwas }
}

class crypt extends security {
private string;
private extender;
private key;

public function __construct() { // Mach was und lade Config über $this->ladeSettings() }
public function cryptMD5() { // prüfen ob extender vorhanden ist und dann zusammen MD5 }
public function cryptSHA1() { // prüfen ob extender vorhanden ist und dann zusammen SHA1 }
public function cryptAES() { // Und ich will, das die Hilfsmethoden aus Security immer hier zur Verfügung stehen über $this->hilfsfunktionX() }
}

So ist das ganze nun einmal Schemenhaft dargestellt, wie ich mir das gedacht habe. Funktionieren tut es. Aber anscheinend gibt es dort ein Designproblem mit dem eigentlichen Prinzip.

Der Vorteil ist, wenn ich das so mache, das die komplette Konfiguration der einzelnen Unterklassen von der Security-Klasse verwaltet wird.

Und genau das meine ich.

Zuletzt editiert von reVerB am 04.07.2011 um 22:13 Uhr (1x Editiert)

Inaktiv

jokey

Try to beat me

Herkunft: Hamburg
Beiträge: 184

# Antwort: 24 - 04.07.2011 um 22:15 Uhr

04.07.2011 um 22:08 Uhr - reVerB:

Der Vorteil ist, wenn ich das so mache, das die komplette Konfiguration der einzelnen Unterklassen von der Security-Klasse verwaltet wird.

Sorry aber das ist einfach komplett falsch.

Deine crypt klasse wird dann über die funktionen ladeSettings und speichereSettings verfügen aber das ist auch schon alles. Du scheinst Klassen und Objekte in einen Topf zu werfen. Es sind aber grundlegend andere Teile von OOP

Klassen sind wie Baupläne für ein Haus. Sie geben die Form vor. Bauen kannst du danach aber viele Häuser und die Räume unterschiedlich ausgestalten. Letzteres sind dann Objekte vom Typ Haus.

Ein Haus kann aber niemals ein anderes Haus beeinflussen. (Die Geschichte, wie das in OOP doch geht, wollen wir mal nicht betrachten, weil man sie in Webanwendungen mit PHP nicht sinnvoll einsetzen kann.)

Ableitungen ("extends") wären dann Baupläne für Hochhäuser, Flachdachhäuser aber immernoch stets Häuser.

Du würdest keine Garage aus einem Haus ableiten

Zuletzt editiert von jokey am 04.07.2011 um 22:16 Uhr (1x Editiert)

Inaktiv

SCHIRI

Weltmeister

Herkunft: Hamburg
Beiträge: 5299

# Antwort: 25 - 04.07.2011 um 22:30 Uhr

Wenn es dir nur um das Laden der Konfiguration geht wäre das hier ein paaenderer Weg:

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

1. / 2. / ...

class Configuration {
  protected $options;

  public function __construct($pfad_zur_config_datei) {
    // ...
  }

  getOption($key) {
    // ...
  }
}

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

1. / 2. / ...

class Encrypter {
  protected $config;
  public function __construct($config) {
   $this->config = $config;
  }

  public function encrypt($text) {
   // ...
  }
}

Ob man die Configuration-Klasse hie aber wirklich braucht oder ob es nicht auch einfach ein Assoziatives Array tut sei mal dahingestellt.
Das würde dich davon abhängig machen eine wie zentrale Rolle der Encrypter in deiner Anwendung spielt.

------------------
www.laszlokorte.de

Zuletzt editiert von SCHIRI am 04.07.2011 um 22:31 Uhr (1x Editiert)

Inaktiv

reVerB
Thread-Ersteller

Geekboy

Beiträge: 1237

# Antwort: 26 - 04.07.2011 um 22:43 Uhr

Deine crypt klasse wird dann über die funktionen ladeSettings und speichereSettings verfügen aber das ist auch schon alles. Du scheinst Klassen und Objekte in einen Topf zu werfen. Es sind aber grundlegend andere Teile von OOP

Ich habe das Gefühl, das unser Verständnis von OOP mal vollkommen auseinander geht.

1. Nein .. Ich schmeiße nicht beides in einem Topf
2. Ja .. Mir ist bewusst, das es sich um "BAUPLÄNE" handelt
3. Nein .. Crypt ODER Client ODER XSPF haben alle Zugriff auf alles, was in der Security-Klasse als Protected deklariert wurde
4. Ja .. Es ist gewollt, das der gesamte Bauplan der Security-Klasse nicht Public ist

Für ladeSettings() kann innerhalb der anderen Klassen ein Parameter übergeben werden, der dafür sorgt, das nur Settings für diese Klassen geladen werden. Das Objekt, das erzeugt wird, bietet nur öffentlich die Methoden an, die zum Objekt gehören. Die Klasse crypt zum Beispiel wird darüber nur mit Hilfsmethoden und Internen Methoden zur Konfigurations-Verwaltung erweitert. Man kann im Grunde die Security-Klasse als Keller des Hauses betrachten. Von außen ist es nicht zu sehen, denn es tut seine Arbeit im Hintergrund.

Klassen sind wie Baupläne für ein Haus. Sie geben die Form vor. Bauen kannst du danach aber viele Häuser und die Räume unterschiedlich ausgestalten. Letzteres sind dann Objekte vom Typ Haus.

Ja ... Crypt kann mehrfach eingesetzt werden. Auch Client kann mehrfach eingesetzt werden und wenn mehrere Formulare auf der Seite sind, kann auch xspf mehrfach zum Einsatz kommen. Der springende Punkt ist einfach, das Security sich nicht selbst instanzieren lässt, da sie einfach nur den Klassen , die diese integrierten Funktionalitäten brauchen erbt.

Ein Haus kann aber niemals ein anderes Haus beeinflussen. (Die Geschichte, wie das in OOP doch geht, wollen wir mal nicht betrachten, weil man sie in Webanwendungen mit PHP nicht sinnvoll einsetzen kann.)

Die Objekte sollen sich nicht gegenseitig beeinflussen. Darum geht es auch nicht. Es ist allgemein logisch, das ich, wenn ich ein Objekt der Klasse crypt instanziere, das ich automatisch in dem Objekt in gewisserweise auch eine eigene Instanz der Klasse Security habe. Das ist aber auch gewollt. Es soll nicht die Verwaltung für die gesamte Sicherheits-Konfiguration sein. Es soll die Verwaltung für die Konfiguration sein, die das Objekt brauch. In einer Instanz von Client steht bei setting1 etwas anderes als bei einer Instanz von crypt.

Security ist im Grunde genommen nur der Handwerke, ohne den das Haus gar nicht stehen würde.

Zuletzt editiert von reVerB am 04.07.2011 um 22:59 Uhr (2x Editiert)

Inaktiv

SCHIRI

Weltmeister

Herkunft: Hamburg
Beiträge: 5299

# Antwort: 27 - 04.07.2011 um 22:58 Uhr

Ok, ich hab jetzt verstanden, was du erreichen willst.

Es ist nur so, dass Vererbung, fass immer der schlechteste Weg ist so etwas umzusetzen.

1. Die Securty-Klasse scheint sich (nur?) um das Laden von Konfiguration zu kümmern und diese Funktionalität den anderen Klassen bereitzustellen. Aber was hat "Konfiguration" mit "Security" zu tun? -> gar nichts. Deshalb ist die Security-Klasse der falsche Ort das unter zu bringen.
Was machst du wenn eine Email-Klasse sich auch Konfigurieren lassen soll? Erbt die dann auch von Security?

2. Wenn eine Klasse von einer anderen Erbt, erbt sie auch die Zuständigkeit mit, denn sie könnte ja eine Methode überschreiben.
Crypt könnte ladeSettings überschreiben. Damit gibst du auch der Crypt-Klasse die Zuständigkeit für das laden de Konfiguration.
Damit vermischt du zwei Zuständigkeiten: Verschlüsselung und Konfiguration in eine Klasse.
Wenn du später einen Fehler im Konfigurations-System entdeckst, oder etwas daran ändern/verbessern willst, musst du die Crypt-Klasse ändern. Das ergibt gar keinen Sinn.

3. Du kannst immer nur von einer Klasse erben. Diese eine Möglichkeit würde ich nicht mit soetwas verschwenden/verbauen.
Nehmen wir mal an du hast eine andere Klasse z.B. eine IPBlacklister-Klasse und diese hat selbst schon eine Eltern-Klasse und du willst jetzt diese Klasse "konfigurierbar im Sinne des Security-Systems" machen, aber nicht die Eltern-Klasse, dann wäre das mit deinem Weg gar nicht möglich, weil du ja die Security-Klasse nicht als Eltern-Klasse hinzufügen kannst.
Noch schwieriger wird es, wenn die Security-Klasse noch 10 helfer-methode hinzubekommen, du in der IpBlocker-Klasse aber nur 4 davon brauchst, aber die IpBlocker-Klasse selber 5 Methoden hat, deren Namen sogar mit den restlichen 6 Methoden der Security-klasse kollidieren.

Mein Fazit: Vererbung ist nicht wirklich eine gute Möglichkeit Code wiederzuverwenden.

Das was du vorhast geht vielleicht in anderen Sprachen, wird aber in Php wenn überhaupt erst mit 5.4 und so genannten "Traits" einigermaßen ermöglicht

------------------
www.laszlokorte.de

Zuletzt editiert von SCHIRI am 04.07.2011 um 23:02 Uhr (1x Editiert)

Inaktiv

reVerB
Thread-Ersteller

Geekboy

Beiträge: 1237

# Antwort: 28 - 04.07.2011 um 23:04 Uhr

Und was ist, wenn ich eine Konfigurationsklasse und eine Helfer-Klasse jeweils als Singleton bastel und diese in die Registry schmeiße? Ich muss dann nur aufpassen, das immer nur das an Konfiguration geladen wird, was man auch wirklich benötigt. Ich kann die Konfiguration ja dann auch Easy in die tempList packen und ebenfalls registrieren.

Naja mal sehen, wie ich das ermögliche.

*EDIT* Verdammt ich habe die Kapselung vergessen. Ich kann ja für jede Konfiguration eine eigene Instanz machen. Das ist der Nachteil, wenn man immer nur prozedural gearbeitet hat ^^

Zuletzt editiert von reVerB am 04.07.2011 um 23:07 Uhr (1x Editiert)

Inaktiv

SCHIRI

Weltmeister

Herkunft: Hamburg
Beiträge: 5299

# Antwort: 29 - 04.07.2011 um 23:24 Uhr

Also ich zweifle ja immer noch etwas an deinen DataContainer-Klassen. Jedes Objekt ist orgendwo ein "dataContainer", weil es ja Daten enthält, aber so generische Klassen zu erstellen und nach "temp", "database" und "file" zu trennen halte ich für wenig sinnvoll.

Es ist allgemein sehr sehr wenig sinnvoll, wenn eine Klasse als Eltern-Klasse für sehr viele andere Klassen hin hält.
Eine Kind-Klasse beinhaltet die Summe Zuständigkeiten von sich selbst und allen Eltern-Klassen. Wenn du versuchst möglich viele Klassen unter einer Eltern-Klasse zu gruppieren hast du eine riesig chaotische Zuständigkeitsvermischung.

Ich würde dir immer noch empfehlen, dir einfach mal ein paar Bibliotheken und Frameworks anzuschauen.

------------------
www.laszlokorte.de

Inaktiv

reVerB
Thread-Ersteller

Geekboy

Beiträge: 1237

# Antwort: 30 - 05.07.2011 um 08:32 Uhr

Also ich habe versucht, mir mal cakePHP anzusehen. Die haben für nahezu alles eine eigene Klasse. Die Vererbungshierarchie ist kaum Nachvollziebar. Dann habe ich mal die beiliegende CD von "PHP 5.3 & MySQL 5.5" von GalileoPress mal genommen und habe mir deren Basissystem angeschaut. Das Teil ist absoluter tinnef. Denn Dort werden zwar Klassen geschrieben. Aber die sind überwiegend statischer Natur und es werden im Beispiel nicht einmal eine Instanz einer Klasse erzeugt.

Ich habe jetzt mal beschlossen, so wenig wie möglich zu erben/vererben, mit Namenräumen zu gruppieren und jetzt einfach mal los zu machen. Die Community sagt mir schon, wenn etwas doof ist. Dann sehe ich mal weiter. Danke bis hierhin schon mal.

*UPDATE*
Hab da mal ne andere Idee. Ich mache einfach nur eine List-Klasse, die mir für Stapelverarbeitungen eine Globale Liste mit Klassen erstellt. Diese Listen packe ich in die Registry, wenn sie global verfügbar sein sollen. Wenn nicht bleiben Sie als normale Instanz. Wenn ich eine Instanz der Datenbank erzeuge kommt die auf jeden Fall in die Registry. Dadurch bleibt die Global erhalten. Wenn ich eine Liste speichern will, dann mach ich das so:
Registry:: Database->saveList($newsList,'news');

Wenn ich einen einfachen Datensatz aus einem Objekt speichern will, dann mach ich das so:
Registry:: Database->save($news,'news');

Das Design der Datenbankklassen (Es sollen ja vielleicht mehrere Datenbanken unterstützt werden) gebe ich per Interface vor.

Ich werde dann versuchen, alle Klassen so Einfach wie möglich halten. Zum Beispiel zum verschlüsseln dann Klassen für cryptMD5, cryptSHA1, cryptAES und cryptWCH. Dadurch habe ich für jeden Schlüssel bzw. jeden Output eine eigene Instanz. Auch hier gebe ich das Design per Interface vor, um so sicher zu stellen, das wenn eine weitere Klasse dazukommt, das diese dann auch auf die selbe Art eingesetzt werden kann.

Für Hilfsfunktionen setze ich dann auch mehrere Klassen ein. Eine zum Beispiel zum vergleichen von Werten, eine zum Bearbeiten von diesem und einem von jedem und habe damit auch immer eigene Instanzen. Durch die Kapselung kann sich jedes Objekt um seine Aufgaben kümmern.

Mal sehen, wie das ganze dann läuft.

*UPDATE2*
Ich habe nun einen automatischen Klassenlader gebastelt, damit das Autoload für die Apps bleibt. Ich nutze dafür ein kleines rekursives Script, da mir den Libs-Folder durchläuft. Nur ich habe irgendwie das Gefühl, das dieser mit wachsender Größe an Performance stark verlieren kann.
So sieht es aus:

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

1. / 2. / ...

<?php
function loadLibs($dir) {
  $handle =  opendir($dir);
  while ($file = readdir($handle)) {
    if ($file != "." && $file != "..") {
      if (is_dir($dir.$file)) {
        loadLibs($dir.$file.'/');
      } elseif(preg_match("=class\.(.*?)\.php=si",$dir.$file)) {
        require_once($dir.$file);
      }
    }
  }
  closedir($handle);
}
loadLibs(LIBS_FOLDER);
?>

Gibt es da eine bessere Variante?

Zuletzt editiert von reVerB am 05.07.2011 um 13:10 Uhr (2x Editiert)

Inaktiv

jokey

Try to beat me

Herkunft: Hamburg
Beiträge: 184

# Antwort: 31 - 11.07.2011 um 01:25 Uhr

baust du das irgendwo ein? den passenden proof of concept expolit schick ich dir dann über die seite -.-

Inaktiv

hajo

VIP - Poster

Herkunft: Barsbüttel
Beiträge: 9411

# Antwort: 32 - 11.07.2011 um 01:27 Uhr

http://www.php.net/manual/de/language.oop5.autoload.php#104282

------------------
ClanSphere - professional clan care starts here

Zuletzt editiert von hajo am 11.07.2011 um 01:29 Uhr (1x Editiert)

Inaktiv

SCHIRI

Weltmeister

Herkunft: Hamburg
Beiträge: 5299

# Antwort: 33 - 11.07.2011 um 01:27 Uhr

damit das Autoload für die Apps bleibt

und was ist so gut daran? Wenn du dir mal anschaust, wie so ein normaler Autoloader, wie er fast überfall benutzt wird, funktioniert, siehst du, dass du dich dabei nicht nur auf einen Ordner oder so beschränken musst.

------------------
www.laszlokorte.de

Zuletzt editiert von SCHIRI am 11.07.2011 um 01:29 Uhr (1x Editiert)

Inaktiv

hajo

VIP - Poster

Herkunft: Barsbüttel
Beiträge: 9411

# Antwort: 34 - 11.07.2011 um 01:30 Uhr

ups url war oben falsch, korrigiert

wollte sagen, dass man niemals __autoload verwenden sollte, sondern wie da steht spl_autoload_register(), damit mögliche drittsoftware ebenfalls die möglichkeit hat autoloader einzubinden

------------------
ClanSphere - professional clan care starts here

Inaktiv

reVerB
Thread-Ersteller

Geekboy

Beiträge: 1237

# Antwort: 35 - 11.07.2011 um 01:43 Uhr

11.07.2011 um 01:25 Uhr - jokey:

baust du das irgendwo ein? den passenden proof of concept expolit schick ich dir dann über die seite -.-

Ok das ist nun ein Kommentar, der mich dazu veranlasst, den Wunsch zu äußern, diesen Thread bitte zu schließen. Kann ich echt drauf verzichten.

Danke nochmals an SCHIRI, der mir per PN viele Tipps gegeben hat. Vielen vielen Dank.

Inaktiv

hajo

VIP - Poster

Herkunft: Barsbüttel
Beiträge: 9411

# Antwort: 36 - 11.07.2011 um 01:47 Uhr

jokey möchte dir doch nichts böses, sondern helfen. das kann eben nicht jeder auch so ausdrücken bzw. in textform kommt manches eben auch mal falsch an

------------------
ClanSphere - professional clan care starts here

Inaktiv

reVerB
Thread-Ersteller

Geekboy

Beiträge: 1237

# Antwort: 37 - 11.07.2011 um 02:00 Uhr

Das Gefühl hatte ich am Anfang auch. Aber der letzte Kommentar war echt von oben herab, das ich das mir echt nicht geben muss. Wo soll ich das nötige Wissen hernehmen?

Neben dem PHP-Werk von Galileo-Press besitze ich noch einen Wälzer über 1100 Seiten von Addison Wesley, 2 PHP-Werke von O'Reily und sogar das PHP-Taschenbuch und nirgends ist auch nur Ansatzweise genauestens beschrieben, was sauber ist und was nicht. Es werden immer nur die Grundlagen zum Thema OOP erklärt. Wie Objekte zu sehen sind, wird zwar an Hand der Beispiele erklärt. Aber wie man vollständig OOP in PHP für größere Projekten nutzt, wird nicht erklärt. Man ist schon gefrustet genug und dann nerven solche Comments einfach nur.

Zuletzt editiert von reVerB am 11.07.2011 um 02:01 Uhr (2x Editiert)

Inaktiv

hajo

VIP - Poster

Herkunft: Barsbüttel
Beiträge: 9411

# Antwort: 38 - 11.07.2011 um 02:11 Uhr

das ist oftmals auch nicht in büchern zu finden, sondern eher durch die erfahrung im laufe der zeit selbst zu wissen. so etwas schreibt auch bislang leider kaum ein buch auf, ausnahmen sind z.b. die design patterns als buch von o'reilly.

------------------
ClanSphere - professional clan care starts here

Inaktiv

SCHIRI

Weltmeister

Herkunft: Hamburg
Beiträge: 5299

# Antwort: 39 - 11.07.2011 um 03:34 Uhr

Aber wie man vollständig OOP in PHP für größere Projekten nutzt, wird nicht erklärt.

Das liegt daran, dass es in Wahrheit niemand weiss

Ich werde jetzt bestimmt wieder von irgendjemandem dafür geschlagen an Php rum zu meckern, aber es ist einfach so, dass Php schon von grund auf nicht auf OOP ausgelegt ist:
- Der Output-Stream ist kein Objekt
- der Request ist kein Objekt/Es gibt keine Request-Klasse
- Response ist kein Objekt/Es gibt keine Response-Klasse
- Es gibt keine File-Klasse bzw selbst wenn es irgendwo in der SPL jetzt eine gibt dreht sich eigentlich alles überall immer noch um irgendwelche Filehandles
- Die kurze Scriptlaufzeit die auf der Idee basiert, das Script nach jedem Request zu beenden macht es offensichtliche fragwürdig wieviele Objekte man instanzieren soll/kann, wenn sie eh wieder verworfen werden.

Dazu kommt noch, dass die ganze OOP-Umsetzung in Php nicht wirklich zu dem passt, was vorher da war.
Variablen waren in Php immer dynamisch. Man konnte in eine Variable, in der Vorher ein String war, ein Array oder ein Integer packen.

Trotzdem bietet die Objektorientierung einen Haufen an Vorteilen. Also hat es sich in den letzten Jahren doch immer weiter durchgesetzt auch in Php stark objektorientiert zu arbeiten. Wie genau man das aber am besten macht, muss sich aber erstmal herausstellen.

- Schreibt man sich eine eigene Request und Response Klasse? Oder verzichtet man an der Stelle auf OOP?
- Sind diese Klassen nur Wrapper für die von Php vorgekauten Suberglobals? Oder fängt man an den QueryString und den RequestBody noch mal selbst zu parsen?
- Wie schafft man überhaupt mit den unzähligen Objekten performant noch klar zu kommen, wenn man sich Request-übergreifend kaum etwas erhalten kann?

Das kann dir einfach niemand erklären. Es gibt verschiedene Wege mit all dem umzugehen. Ungefähr so viele, wie es auch Frameworks gibt. An so gut wie jedem Framework sieht man aber, von welchem anderen Framework aus einer anderen Sprache es kopiert ist.

CakePhp ist z.B. sehr stark von Rails inspiriert, was den Aufbau angeht. Allerdings lässt sich so gut wie nichts einfach so aus Ruby nach Php kopieren. Das führt also dazu, dass an vielen Stellen irgendwelche Kompromisse eingegangen wurden, damit es zumindest ähnlich aussieht. Ob das aber für Php der richtige Weg ist, kann ich dir nicht sagen - und ich denke auch niemand anders - vermutlich ist er es aber nicht.

Symfony2 hingegen ist sehr stark an in Java verwendeten Konzepten orientiert. Das macht schon mehr Sinn, weil das Klassen- und Objekt-Konzept von Php dem von Java schon sehr viel ähnliches ist, als dem von Ruby oder Python.
Trotzdem gibt es auch hier wieder einiges, was besonders vorteilhaft an Java ist, was sich einfach nicht auf Php übertragen lässt. Zum einen wäre da wieder die Request-übergreifende Laufzeit zum anderen Features wie "Annotations". Letzteres wird z.B. in Symfony2 (aber auch in vielen anderen Frameworks), mit einem sehr komplexen DependenyIncject, Caching und Reflection-Pasrsing-System nachgebaut. Der Code-Overhead dahinter ist meiner Meinung nach absolut absurd und ver XXXXX-Facht die Komplexität, ermöglicht aber auch wieder einiges und ist nach gewissen Maßstäben "sauber", was die Trennung von Zuständigkeiten angeht. Ausserdem lässt sich so etwas sehr sehr performant umsetzen.

Dann gibt es noch wieder andere Frameworks, die noch andere Wege gehen oder verschiedene Wege der Umsetzung mischen.

Ich bin auch nicht mehr ganz sicher, wie du dir unsere Hilfe hier vorstellst.

------------------
www.laszlokorte.de

Inaktiv

reVerB
Thread-Ersteller

Geekboy

Beiträge: 1237

# Antwort: 40 - 11.07.2011 um 08:40 Uhr

Oha. Nach dieser Erklärung weiß ich selbst nicht, wie ich mir diese noch vorstellen soll ...

Die OOP in VB.NET oder C# lässt sich super einfach umsetzen, da im Hintergrund ein großes Framework werkelt und dann sind die Sprachen auch an sich mit allem gespickt, was man benötigt. PHP hat was OOP angeht gerade mal einen Teil von dem in der Sprache verankert, was in den .NET Sprachen vorhanden ist. Da muss man sich keine Register schreiben, da man einfach eine globale Collection für Objekte anlegen kann.

Ich schiebe das ganze erst einmal auf die lange Bank, da mir schlichtweg aktuell die Zeit fehlt, mir die Frameworks anzusehen und zu schauen, wie dort die Sachen umgesetzt werden. Das ist für mich dann auch der 2. Grund, warum er Thread zu kann. Ich dachte ich hätte mir das ganze mit OOP einfacher machen können. Aber am einfachsten ist es wirklich, das ganze prozedural zu machen.

Inaktiv

Antworten: 44

Seite < 1 [2] 3 >

Sie müssen sich registrieren, um zu antworten.

Forum - Thema
Nächstes Thema ->
Forum -> Support -> PHP und SQL -> Verständnis-Frage: OOP