S.O.L.I.D는 Robert C. Martin이 제안한 First 5 Object Oriented Design (OOD) 원칙의 약어로, Uncle Bob으로 더 잘 알려져 있습니다.
이러한 지침을 사용하면 확장 가능하고 유지 관리 가능한 소프트웨어를 더 쉽게 개발할 수 있습니다. 또한 코드를 더욱 간소화하고 리팩토링하기 쉽게 만듭니다. 또한 민첩한 개발 및 적응형 소프트웨어 개발의 일부입니다.
Remarks: 이 글은 단순한 "Welcome to _S.O.L.I.D" 글이 아니며, 이 글은 S.O.L.I.D가 무엇인지 명확히 하고자 합니다. (관련 튜토리얼 추천: php 비디오 튜토리얼)
확장된 약어는 복잡해 보일 수 있지만 실제로는 이해하기 쉽습니다.
S.O.L.I.D가 우리가 더 나은 개발자가 되는 데 도움이 되는 이유를 이해하기 위해 각 원칙을 살펴보겠습니다.
약어는 S.R.P입니다. 이 원칙의 내용은 다음과 같습니다.
클래스는 클래스를 변경하는 요소를 하나만 가질 수 있으며, 이는 클래스가 단일 책임만 가져야 함을 의미합니다. .
예를 들어, 몇 가지 모양이 있고 이러한 모양의 전체 면적을 계산하려고 한다고 가정해 보겠습니다. 네, 쉽죠?
class Circle {
public $radius;
public function construct($radius) {
$this->radius = $radius;
}
}
class Square {
public $length;
public function construct($length) {
$this->length = $length;
}
}먼저 그래픽 클래스를 생성하고 이 클래스의 생성자가 필요한 매개변수를 초기화합니다. 다음으로 AreaCalculator 클래스를 생성한 후, 지정된 도형의 전체 면적을 계산하는 논리 코드를 작성합니다.
class AreaCalculator {
protected $shapes;
public function __construct($shapes = array()) {
$this->shapes = $shapes;
}
public function sum() {
// logic to sum the areas
}
public function output() {
return implode('', array(
"",
"Sum of the areas of provided shapes: ",
$this->sum(),
""
));
}
}AreaCalculator 이 메서드를 사용하려면 이 클래스를 인스턴스화하고 그래픽 배열을 전달하여 페이지 하단에 출력 콘텐츠를 표시하면 됩니다.
$shapes = array( new Circle(2), new Square(5), new Square(6) ); $areas = new AreaCalculator($shapes); echo $areas->output();
출력 방법의 문제점은 AreaCalculator가 데이터 출력 로직을 처리한다는 것입니다. 그렇다면 사용자가 json이나 다른 형식으로 데이터를 출력하고 싶다면 어떻게 해야 할까요?
모든 로직은 SRP(단일 책임 원칙)를 정확히 위반하는 AreaCalculator 클래스에 의해 처리됩니다. AreaCalculator 클래스는 그래프의 전체 영역 계산만 담당해야 하며, 사용자는 json 또는 HTML 형식의 데이터를 원합니다.
이 문제를 해결하려면 SumCalculatorOutputter 클래스를 생성하고 이를 사용하여 모든 그래프의 전체 영역을 표시하는 방법에 대한 필수 표시 로직을 처리할 수 있습니다.
SumCalculatorOutputter 클래스는 다음과 같이 작동합니다.
$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();
이제 사용자에게 출력하려는 데이터 형식은 SumCalculatorOutputter 클래스에 의해 처리됩니다.
객체와 엔터티는 확장을 위해 열려야 하지만 수정을 위해 닫혀 있어야 합니다.
간단히 말하면 클래스는 자체 수정 없이 쉽게 기능을 확장할 수 있어야 합니다. AreaCalculator 클래스, 특히 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);
}sum 방법을 사용하여 더 많은 도형의 면적을 계산하려면 if/else 블록을 더 추가해야 하지만 이는 열기 및 닫기 원칙에 위배됩니다.
이 sum 방법을 더 좋게 만드는 방법은 각 모양의 면적을 계산하는 코드 로직을 sum 방법에서 옮겨 각 모양 클래스에 넣는 것입니다.
class Square {
public $length;
public function __construct($length) {
$this->length = $length;
}
public function area() {
return pow($this->length, 2);
}
}동일한 작업을 사용해야 합니다. Circle 클래스를 처리하고 클래스에 area 메소드를 추가하세요. 이제 모든 모양의 영역 합계를 계산하는 것은 다음과 같이 간단해야 합니다.
public function sum() {
foreach($this->shapes as $shape) {
$area[] = $shape->area();
}
return array_sum($area);
}다음으로 다른 모양 클래스를 만들고 코드를 손상하지 않고 합계를 계산할 때 이를 전달할 수 있습니다. 하지만 이제 또 다른 질문이 생깁니다. AreaCalculator에 전달된 개체가 실제로 모양인지 또는 모양 개체에 area 메서드가 있는지 어떻게 알 수 있습니까?
인터페이스 코딩은 S.O.L.I.D 연습의 일부입니다. 예를 들어 다음 예에서는 각 모양 클래스가 구현할 인터페이스 클래스를 만듭니다.
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);
}
}AreaCalculator의 sum 메서드에서 인스턴스가 제공된 모양 클래스는 ShapeInterface의 구현입니다. 그렇지 않으면 예외가 발생합니다:
public function sum() {
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로 대체될 때 변경되지 않습니다. 그런 다음 유형 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 implode('', array(
'',
'Sum of the areas of provided shapes: ',
$this->calculator->sum(),
''
));
}
}如果我们运行像这样一个例子：
$areas = new AreaCalculator($shapes); $volumes = new AreaCalculator($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 一开始似乎很难掌握，但只要不断地使用和遵守其原则，它将成为你的一部分，使你的代码易被扩展、修改，测试，即使重构也不容易出现问题。
相关PHP面向对象视频教程推荐：《PHP面向对象视频教程》
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
