SOLID design principles (programming) - Versionsgeschichte

37.49.72.8: /* Interface Segregation Principle */

2020-01-23T19:37:41Z

Interface Segregation Principle

37.49.72.8: /* Factory Pattern */

2020-01-23T19:37:21Z

Factory Pattern

37.49.72.8: Die Seite wurde neu angelegt: „Design Prinzipien zu robusterem und besser lesbarem Code. https://www.youtube.com/watch?v=WQue1AN93YU Dafür gibt es ein paar Benennungs Muster, Design Prin…“

2020-01-23T19:08:40Z

Die Seite wurde neu angelegt: „Design Prinzipien zu robusterem und besser lesbarem Code. https://www.youtube.com/watch?v=WQue1AN93YU Dafür gibt es ein paar Benennungs Muster, Design Prin…“

Neue Seite

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.
<syntaxhighlight lang="php">
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");
}
}
</syntaxhighlight>
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.

@@ Zeile 69: / Zeile 69: @@
 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.
-* Wenn
+TODO - when needed :-)

@@ Zeile 42: / Zeile 42: @@
      throw new Exception("Unsupported payment option");
+   }
+}
 </syntaxhighlight>
 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.