OOP-Design-Ansatz für zwei interagierende Klassen

Question

Was sind die relativen Vorteile/Nachteile der Verkettung von Klassen (oder besser gesagt, die Verwendung der Ergebnisse einer Klasse zur Generierung einer anderen Klasse) im Vergleich zu verschachtelten Klassen?

Ich versuche mein Benutzer/Authentifizierungssystem umstrukturieren und frage mich, ob;

• myAuthClass als Utility handeln sollte und wenn Anmeldung erfolgreich ist, erstellen Sie einfach ein neues Objekt myUserClass
• oder ob die myAuthClass die myUserClass intern schaffen sollte (dh $ this-> user = new myUserClass)
• oder auch wenn myUserClass bei Bedarf myAuthClass aufrufen sollte (dh wenn ein Benutzer versucht sich anzumelden) und seine interne Struktur (neue E-Mails, Favoriten, Warenkorb usw.) bei Bedarf aktualisiert.

Wie Sie sehen können, bin ich ein bisschen ein OOP n00b. Zeitweise scheint es mir möglich zu sein, für jede der Methoden zu plädieren, deshalb bin ich daran interessiert, von anderen Menschen über die verschiedenen Ansätze zu hören.

Prost.

Answer 1

Von einer accademischen Perspektive sind alle 3 Optionen falsch, da sie gegen konkrete Implementierungen und nicht gegen eine abstrakte Schnittstelle programmiert werden. Als solche sind sie direkt miteinander verbunden, was die Wiederverwendung begrenzt - Sie verwenden sie beide wieder oder nicht.

Sie könnten IUserClass oder IAuthClass generieren und diese abstrakte Schnittstelle in eine konkrete Klasse implementieren und dann würde ich für eine Situation gehen, in der die Authentifizierungsklassenimplementierung eine IUserClass bei der Authentifizierung zum Auffüllen nahm oder der Benutzerklasse eine Implementierung von IAuthClass für die Authentifizierung. In jedem Szenario bietet dies die größte Flexibilität, da die Auth-Klasse wiederverwendet werden kann und verschiedene Versionen der UserClass generiert werden können, oder die Benutzerklasse die Möglichkeit hat, mehrere verschiedene Authentifizierungsmechanismen zu verwenden, solange sie erben von IAuthClass.

Der zweite Ansatz, der Benutzerklasse ein Authentifizierungsobjekt zu geben (das IAuthClass implementiert), wäre meine Präferenz, da sich Authentifizierungsmechanismen auch bei einer einzigen Anwendung unterscheiden, während sich die Benutzerklasse weniger ändert. Aber um richtig zu sein, sollte keines auf einer konkreten Implementierung basieren.

Dies kann jedoch als übertrieben angesehen werden, also ist es ein Urteilsspruch.

Answer 2

Zuerst empfehle ich Ihnen, das Adaptermuster zu verwenden. Sie sollten über eine abstrakte Klasse verfügen, die die Schnittstelle (die öffentlichen Methoden) definiert, als Sie eine Klasse erstellen, die einen bestimmten Authentifizierungstyp implementiert. Zum Beispiel können Sie eine Klasse/einen Adapter für die DB-Basisauthentifizierung, eine für die LADP-Authentifizierung usw. erstellen.

Die beste Sache, anstatt das Rad neu zu erfinden, sollten Sie eine fertige Lösung verwenden. Ich habe Zend_Auth benutzt, welches das Adaptermuster implementiert. Mit Zend_Auth können Sie gute OOP-Methoden, das Adaptermuster, die Verwendung von Interfaces und abstrakte Klassen verstehen, wenn Sie das möchten.

Hier können Sie sehen, wie ich Zend_Auth für ein Intranet verwendet habe;

 protected function Authentication() { 
     $strEmail = trim($this->txtEmail->Text); 
     $this->txtPassword->Text = trim($this->txtPassword->Text); 
     // do the process of authentication, AD and then DB 
     // Get a reference to the singleton instance of QAuth 
     $auth = QAuth::getInstance(); 
     // Set up the authentication adapter 
     $authAdapter = new QAuth_Adapter_WebService(__LOGIN_WS_URL__, 
      $strEmail, $this->txtPassword->Text 
     ); 

     // Attempt authentication, saving the result 
     $result = $auth->authenticate($authAdapter); 

     if ($result->isValid()) { 
      $objUser = User::LoadByEmail($strEmail); 

      // if there is not a user's record create one 
      if(!$objUser) { 
       $this->User_Create($strEmail); 
       $objUser = User::LoadByEmail($strEmail); 
      } 

      $crypt = new Encryption(); 
      $encr = $crypt->encrypt(__KEY__, $objUser->UserID);    
      $_SESSION['user_id'] = $encr; 
      setcookie('user_id', $_SESSION['user_id'], time()+(3600*24*365*20)); 
      $this->Intranet1Integration($objUser->UserID); 
      QApplication::Redirect('http://'.__URL__.'/index.php');  
     } 
     else { 
      QApplication::DisplayAlert(
       'Log on failed. You must provide a Company email and a correct password.' 
      ); 
     } 
    } 

Answer 3

Der Hauptvorteil Klassen Verkettungs macht sie unabhängig voneinander ein absolut keine (oder sehr viel weniger) Wirkung auf die anderen so modifiziert hat.Wenn Sie beispielsweise die Authentifizierungsmethode ändern möchten, müssen Sie den Benutzer nicht ändern und umgekehrt.

andere kleine Vorteile kommen für beiden Methoden, aber diese Wartbarkeit ist die wichtigste hier