Moin!

Das ist mir schon klar das dies so aussehen würde. Allerdings habe ich dann das gleiche Problem wie vorher, oben müssen die die Klassen instanziert werden.

Wenn ich mir in deinem Anfangsposting die Klassenauflistung so ansehe, bin ich sowieso der Meinung, dass diese Klassen jeweils viel zuviel tun.

Nur mal so als herausgegriffenes Beispiel: Eine Klasse "Blog" - was tut die bei dir? Alles im Blog? Oder wieviele Unterklassen werden durch diese Klasse aufgerufen?

Ne Klasse ist bei mir immer so aufgebaut (PSEUDO):

class Klasse1{

public function __construct(){

if(isset($_POST['formular1'])) self::bearbeiteFormular1();
   if(isset($_POST['formular2'])) self::bearbeiteFormular3();
   if(isset($_POST['formular3'])) self::bearbeiteFormular3();
}

private static function bearbeiteFormular1(){}
private static function bearbeiteFormular2(){}
private static function bearbeiteFormular3(){}

}

  
Das ist alles andere als OOP. Wozu brauchst du Klassen? Als Namespace-Separator vielleicht, aber das war es dann auch.  
  

> Also. Um auf ein Formulareingabe zu reagieren, \_muss\_ die Klasse schon vorher instanziert sein, damit im Konstruktor auf den Request passend reagiert werden kann. Das Autoloading kann ja nicht eingreifen weil PHP nicht automatisch weiß was ein Request für eine Klasse benötigt. Das muss ich ihm ja sagen.  
  
Das Problem ist, dass du die Klasse instanziierst, damit der Konstruktor aufgerufen wird, danach aber nur statische Methoden benutzt. Entscheide dich mal: Entweder eine Klasse wird als Objekt instanziiert, dann sind ihre Methoden nicht statisch, und es macht in der Logik der Applikation auch Sinn, dass es von einundderselben Klasse mehr als ein Objekt parallel im gleichen Skriptkontext gibt. Beispiel dafür wäre beispielsweise ein Array von "Kommentarobjekten" in einem "Blogeintragobjekt".  
  
Alternativ ist eine Klasse durchgehend statisch. Dann hat sie nicht mehr viel von OOP, sondern dient eigentlich nur noch dazu, die prozedurale Vorgehensweise mit freundlicher klingenden Namespaces zu verschönern, aber für gewisse Hilfsfunktionen, die man zentralisiert anbieten will, ist das durchaus erlaubt. Nur sollte nicht der gesamte Code daraus bestehen.  
  

> Bei 10 Klassen mit jeweils mindestens 3 Request-Handlings im Konstruktor wären das bei jedem Request 30 If-Schleifen die durchfahren werden.  
  
Es gibt keine If-Schleifen.  
  
Und für die Realisierung des Request-Handlings bist du ja selbst verantwortlich. dedlfix hat dazu ja auch einen Kommentar abgegeben, der genau in die richtige Richtung zielt. Mache dich mit dem MVC-Pattern vertraut. Nutze ein Framework, das dir zu diesem Zweck die meiste Nerv-Arbeit abnehmen kann. MVC zu realisieren ist eine recht langweilige Standardaufgabe, die viel Zeit schluckt, wenn man sie selbst realisieren will, ohne nennenswerte Vorteile gegenüber bestehenden Frameworks zu bieten.  
  

> Nun will ich das Autoloading irgendwie nutzen.  

[...]  

> Schade nur das mir das irgendwie null gefällt vom Aufbau, es sieht so prozedual aus, ich würde das viel lieber universeller, globaler, unabhängiger machen - OOP.  
  
Tja, das Problem dürfte insgesamt eher in der Tatsache begründet liegen, dass dein bisheriger Ansatz des Request-Parsings suboptimal ist, und du ohne größere Umbauten aus dieser Falle auch nicht herauskommst. Abgesehen vom ebenfalls suboptimalen Einsatz von OOP.  
  
 - Sven Rautenberg