Lassen Sie uns über die fünf Grundprinzipien des objektorientierten PHP-Designs (S.O.L.I.D) sprechen.

Dieser Artikel führt Sie durch die fünf Grundprinzipien des objektorientierten Lassen Sie uns über die fünf Grundprinzipien des objektorientierten PHP-Designs (S.O.L.I.D) sprechen.-Designs (S.O.L.I.D). Ich hoffe, er wird Ihnen hilfreich sein!

S.O.L.I.D ist ein Akronym für Die 5 Prinzipien des objektorientierten Designs (OOD), vorgeschlagen von Robert C. Martin, besser bekannt als Uncle Bob.

Diese Richtlinien erleichtern die Entwicklung skalierbarer und wartbarer Software. Außerdem wird der Code dadurch rationalisiert und lässt sich einfacher umgestalten. Auch Teil der agilen Entwicklung und der adaptiven Softwareentwicklung.

Bemerkungen: Dies ist kein einfacher Einführungsartikel „Willkommen bei _*S.O.L.I.D*“, dieser Artikel soll klären, was *S.O.L.I.D*** ist.

S.O.L.I.D bedeutet:

Das erweiterte Akronym sieht vielleicht kompliziert aus, ist aber eigentlich ziemlich einfach zu verstehen.

• S – Einzelfunktionsprinzip
• O – Öffnungs- und Schließprinzip
• L – Liskov-Substitutionsprinzip
• I – Schnittstellenisolationsprinzip
• D – Abhängigkeit Version Prinzip

Schauen wir uns die einzelnen Prinzipien an, um zu verstehen, warum S.O.L.I.D uns dabei helfen kann, bessere Entwickler zu werden.

Prinzip der Einzelverantwortung

Die Abkürzung lautet

S.R.P. Der Inhalt dieses Prinzips lautet:

Eine Klasse hat und kann nur einen Faktor haben, der dazu führt, dass sie sich ändert, was bedeutet, dass eine Klasse nur einen Faktor haben sollte haben eine einzige Verantwortung.

Angenommen, wir haben einige Formen und möchten die Gesamtfläche dieser Formen berechnen. Ja, es ist einfach, oder?

class Circle {
    public $radius;

    public function __construct($radius) {
        $this->radius = $radius;
    }
}

class Square {
    public $length;

    public function __construct($length) {
        $this->length = $length;
    }
}

Zuerst erstellen wir die Grafikklasse und der Konstruktor dieser Klasse initialisiert die erforderlichen Parameter. Erstellen Sie als Nächstes die Klasse „AreaCalculator“ und schreiben Sie dann den Logikcode, um die Gesamtfläche der angegebenen Form zu berechnen.

class AreaCalculator {

    protected $shapes;

    public function __construct($shapes = array()) {
        $this->shapes = $shapes;
    }

    public function sum() {
        // logic to sum the areas
    }

    public function output() {
        return 'Sum of the areas of provided shapes: ' . $this->sum();
    }
}

AreaCalculator Um die Methode zu verwenden, instanziieren wir einfach diese Klasse und übergeben ein Grafikarray, um den Ausgabeinhalt unten auf der Seite anzuzeigen. Das Problem mit der

$shapes = array(
    new Circle(2),
    new Square(5),
    new Square(6)
);

$areas = new AreaCalculator($shapes);

echo $areas->output();

output-Methode besteht darin, dass AreaCalculator die Datenausgabelogik verwaltet. Was also, wenn der Benutzer die Daten in JSON oder anderen Formaten ausgeben möchte?

Die gesamte Logik wird von der Klasse AreaCalculator

verwaltet, was genau gegen das Single Responsibility Principle (SRP) verstößt; die Klasse

AreaCalculator sollte nur für die Berechnung der Gesamtfläche des Diagramms verantwortlich sein, es sollte ihr egal sein, ob die Der Benutzer möchte Daten im JSON- oder HTML-Format. Um dieses Problem zu lösen, können Sie eine SumCalculatorOutputter

-Klasse erstellen und diese verwenden, um die erforderliche Anzeigelogik dafür zu handhaben, wie die Gesamtfläche aller Diagramme angezeigt werden soll. Die

SumCalculatorOutputter

-Klasse funktioniert folgendermaßen:

$shapes = array(
    new Circle(2),
    new Square(5),
    new Square(6)
);

$areas = new AreaCalculator($shapes);
$output = new SumCalculatorOutputter($areas);

echo $output->JSON();
echo $output->HAML();
echo $output->HTML();
echo $output->JADE();

Jetzt wird jedes Datenformat, das Sie an den Benutzer ausgeben möchten, von der SumCalculatorOutputter-Klasse verarbeitet.

Öffnungs- und SchließprinzipObjekte und Entitäten sollten für Erweiterungen offen, für Änderungen jedoch geschlossen sein.

Einfach ausgedrückt: Eine Klasse sollte in der Lage sein, ihre Funktionalität problemlos zu erweitern, ohne sich selbst zu ändern. Werfen wir einen Blick auf die Klasse

AreaCalculator

, insbesondere auf die Methode

sum.

public function sum() {
    foreach($this->shapes as $shape) {
        if(is_a($shape, 'Square')) {
            $area[] = pow($shape->length, 2);
        } else if(is_a($shape, 'Circle')) {
            $area[] = pi() * pow($shape->radius, 2);
        }
    }

    return array_sum($area);
}

Wenn wir die sum-Methode verwenden möchten, um die Fläche mehrerer Formen zu berechnen, müssen wir weitere if/else-Blöcke

hinzufügen, was jedoch gegen das Öffnungs- und Schließprinzip verstößt. Die Möglichkeit, diese Summe-Methode zu verbessern, besteht darin, die Codelogik, die die Fläche jeder Form berechnet, aus der Summenmethode zu entfernen und sie in jede Formklasse einzufügen:

class Square {
    public $length;

    public function __construct($length) {
        $this->length = $length;
    }

    public function area() {
        return pow($this->length, 2);
    }
}

Die gleiche Operation sollte verwendet werden Behandeln Sie die Klasse Circle und fügen Sie der Klasse eine Methode

area

hinzu. Jetzt sollte die Berechnung der Summe der Flächen einer beliebigen Form so einfach sein wie:

public function sum() {
    $area = [];
    foreach($this->shapes as $shape) {
        $area[] = $shape->area();
    }

    return array_sum($area);
}

Als nächstes können wir eine weitere Formklasse erstellen und diese bei der Berechnung der Summe übergeben, ohne unseren Code zu beschädigen. Aber jetzt stellt sich eine andere Frage: Wie können wir wissen, dass das an AreaCalculator übergebene Objekt tatsächlich eine Form ist oder dass es im Formobjekt eine

area

-Methode gibt? Schnittstellencodierung ist Teil des Übens von S.O.L.I.D. Im folgenden Beispiel erstellen wir beispielsweise eine Schnittstellenklasse, die jede Formklasse implementiert:

interface ShapeInterface {
    public function area();
}

class Circle implements ShapeInterface {
    public $radius;

    public function __construct($radius) {
        $this->radius = $radius;
    }

    public function area() {
        return pi() * pow($this->radius, 2);
    }
}

In der Summenmethode unseres AreaCalculator können wir prüfen, ob die bereitgestellte Instanz von Die Shape-Klasse ist eine Implementierung von

ShapeInterface

, andernfalls werfen wir eine Ausnahme aus:

public function sum() {
    $area = [];
    foreach($this->shapes as $shape) {
        if(is_a($shape, 'ShapeInterface')) {
            $area[] = $shape->area();
            continue;
        }

        throw new AreaCalculatorInvalidShapeException;
    }

    return array_sum($area);
}

里氏替换原则

如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。

这句定义的意思是说：每个子类或者衍生类可以毫无问题地替代基类/父类。

依然使用 AreaCalculator 类, 假设我们有一个 VolumeCalculator 类，这个类继承了  AreaCalculator 类：

class VolumeCalculator extends AreaCalulator {
    public function construct($shapes = array()) {
        parent::construct($shapes);
    }

    public function sum() {
        // logic to calculate the volumes and then return and array of output
        return array($summedData);
    }
}

SumCalculatorOutputter 类:

class SumCalculatorOutputter {
    protected $calculator;

    public function __constructor(AreaCalculator $calculator) {
        $this->calculator = $calculator;
    }

    public function JSON() {
        $data = array(
            'sum' => $this->calculator->sum();
        );

        return json_encode($data);
    }

    public function HTML() {
        return 'Sum of the areas of provided shapes: ' . $this->calculator->sum();
    }
}

如果我们运行像这样一个例子：

$areas = new AreaCalulator($shapes);
$volumes = new VolumeCalculator($solidShapes);

$output = new SumCalculatorOutputter($areas);
$output2 = new SumCalculatorOutputter($volumes);

程序不会出问题， 但当我们使用$output2 对象调用 HTML 方法时 ，我们接收到一个 E_NOTICE 错误，提示我们 数组被当做字符串使用的错误。

为了修复这个问题，只需：

public function sum() {
    // logic to calculate the volumes and then return and array of output
    return $summedData;
}

而不是让VolumeCalculator 类的 sum 方法返回数组。

$summedData 是一个浮点数、双精度浮点数或者整型。

接口隔离原则

使用方（client）不应该依赖强制实现不使用的接口，或不应该依赖不使用的方法。

继续使用上面的 shapes 例子，已知拥有一个实心块，如果我们需要计算形状的体积，我们可以在 ShapeInterface 中添加一个方法：

interface ShapeInterface {
    public function area();
    public function volume();
}

任何形状创建的时候必须实现 volume 方法，但是【平面】是没有体积的，实现这个接口会强制的让【平面】类去实现一个自己用不到的方法。

ISP 原则不允许这么去做，所以我们应该创建另外一个拥有 volume 方法的SolidShapeInterface 接口去代替这种方式，这样类似立方体的实心体就可以实现这个接口了：

interface ShapeInterface {
    public function area();
}

interface SolidShapeInterface {
    public function volume();
}

class Cuboid implements ShapeInterface, SolidShapeInterface {
    public function area() {
        //计算长方体的表面积
    }

    public function volume() {
        // 计算长方体的体积
    }
}

这是一个更好的方式，但是要注意提示类型时不要仅仅提示一个 ShapeInterface 或 SolidShapeInterface。
你能创建其它的接口，比如 ManageShapeInterface ,并在平面和立方体的类上实现它，这样你能很容易的看到有一个用于管理形状的api。例：

interface ManageShapeInterface {
    public function calculate();
}

class Square implements ShapeInterface, ManageShapeInterface {
    public function area() { /Do stuff here/ }

    public function calculate() {
        return $this->area();
    }
}

class Cuboid implements ShapeInterface, SolidShapeInterface, ManageShapeInterface {
    public function area() { /Do stuff here/ }
    public function volume() { /Do stuff here/ }

    public function calculate() {
        return $this->area() + $this->volume();
    }
}

现在在 AreaCalculator 类中，我们可以很容易地用 calculate替换对area 方法的调用，并检查对象是否是 ManageShapeInterface 的实例，而不是 ShapeInterface 。

依赖倒置原则

最后，但绝不是最不重要的：

实体必须依赖抽象而不是具体的实现．即高等级模块不应该依赖低等级模块，他们都应该依赖抽象．

这也许听起来让人头大，但是它很容易理解．这个原则能够很好的解耦，举个例子似乎是解释这个原则最好的方法：

class PasswordReminder {
    private $dbConnection;

    public function __construct(MySQLConnection $dbConnection) {
        $this->dbConnection = $dbConnection;
    }
}

首先 MySQLConnection 是低等级模块，然而　PasswordReminder 是高等级模块，但是根据 S.O.L.I.D. 中 D 的解释：依赖于抽象而不依赖与实现， 上面的代码段违背了这一原则，因为 PasswordReminder 类被强制依赖于 MySQLConnection 类．

稍后，如果你希望修改数据库驱动，你也不得不修改 PasswordReminder 类，因此就违背了 Open-close principle．

此 PasswordReminder 类不应该关注你的应用使用了什么数据库，为了进一步解决这个问题，我们「面向接口写代码」，由于高等级和低等级模块都应该依赖于抽象，我们可以创建一个接口：

interface DBConnectionInterface {
    public function connect();
}

这个接口有一个连接数据库的方法，MySQLConnection 类实现该接口，在 PasswordReminder 的构造方法中不要直接将类型约束设置为 MySQLConnection 类，而是设置为接口类，这样无论你的应用使用什么类型的数据库，PasswordReminder 类都能毫无问题地连接数据库，且不违背 开闭原则．

class MySQLConnection implements DBConnectionInterface {
    public function connect() {
        return "Database connection";
    }
}

class PasswordReminder {
    private $dbConnection;

    public function __construct(DBConnectionInterface $dbConnection) {
        $this->dbConnection = $dbConnection;
    }
}

从上面一小段代码，你现在能看出高等级和低等级模块都依赖于抽象了。

总结

说实话，S.O.L.I.D 一开始似乎很难掌握，但只要不断地使用和遵守其原则，它将成为你的一部分，使你的代码易被扩展、修改，测试，即使重构也不容易出现问题。

Empfohlenes Lernen: „Lassen Sie uns über die fünf Grundprinzipien des objektorientierten PHP-Designs (S.O.L.I.D) sprechen.-Video-Tutorial“

Das obige ist der detaillierte Inhalt vonLassen Sie uns über die fünf Grundprinzipien des objektorientierten PHP-Designs (S.O.L.I.D) sprechen.. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!