SOLID design principles (programming)

Design Prinzipien zu robusterem und besser lesbarem Code.

https://www.youtube.com/watch?v=WQue1AN93YU

Dafür gibt es ein paar Benennungs Muster, Design Prinzipien aber auch ein paar nicht so kompliziert umzusetzende Programmier Patterns.

Stichworte

Open Closed Principle

Entität (z.B. Klasse) offen für Erweiterung aber geschlossen für Modifikation. Funktionalität wird durch Erweitern des Codes nicht durch Ändern erreicht. Dadurch weniger Fehleranfällig. Wie macht man das ? Separiere Verhaltensweisen.

Programming Patterns

Factory Pattern

Create different Class Instances on Runtime

Bsp.

interface PayableInterface
{
  public function pay();
}
class CreditCardPayment implements PayableInterface{
  public function pay()
  {
    // do credit card payment
  }
}
class PaypalPayment implements PayableInterface{
  public function pay()
  {
    // do paypal payment
  }
}
//...
class PaymentFactory{
  public function initializePayment($type)
  {
    if($type === 'credit'){
      return new CreditCardPayment();
    } elseif($type === 'paypal'){
      return new PaypalPayment();
    }
    throw new Exception("Unsupported payment option");
  }
}

// eine pay Funktion würde etwa so aussehen
public function pay(Request $request)
{
  $paymentFactory = new PaymentFactory();
  $payment = $paymentFactory->initializePayment($request->type);
  $payment->pay();
}

Indem man die PaymentFactory dazwischen schaltet und jeder Zahlungsweise die pay Funktion implementiert muss man nur die Factory anpassen und eine neue Klasse hinzufügen. Hätte man die Zahlungsoptionen in einer Klasse zusammengefasst, müßte man mit jeder neuen Option die Klasse ändern. Dadurch wächst die Gefahr dass sich neue Fehler einschleichen können.

• Die Payment Factory gibt den passenden Objekttyp zurück.

Liskov Substitution

Siehe Link oben

• Wenn du eine Funktion aus deiner Parent Klasse überschreiben musst ist evtl. etwas falsch an deinem Entwurf
• Wenn Funktionen gar nicht mehr funktionieren ist evtl. etwas falsch.
• Wenn das Programm in manchen Situationen funktioniert in manchen aber nicht und du musst es mit einer Exception abfangen dann ist evtl. etwas falsch.

Lösungsansätze:

• Man erstellt Interfaces die man implementieren kann oder weglassen wenn es in der Kindklasse nicht benötigt wird.

Interface Segregation Principle

Der Client sollte nicht gezwungen werden Funktionen nutzen zu müssen, die er nicht benötigt. Real World Beispiel: Multiadapterkabel aber du brauchst nur einen Stecker davon.

• Lieber mehrere kleine Interfaces als ein großes.

TODO - when needed :-)