PHP 객체지향 디자인(SOLID)의 5가지 원칙 요약-PHP 튜토리얼-php.cn

이 글은 주로 PHP 객체지향 디자인(SOLID)의 5가지 원칙을 요약한 것입니다. 참고할만한 가치가 있습니다. 이제 도움이 필요한 친구들이 참고할 수 있도록 공유하겠습니다.

PHP 디자인 원칙에 대한 리뷰 , "PHP 핵심" 기술 및 모범 사례", "민첩한 개발 원칙, 패턴 및 사례", 기사 PHP 객체 지향 디자인의 5가지 원칙, 디자인 패턴 원칙 SOLID

단일 책임 원칙(SRP)

정의/특성을 참조하세요.

클래스 변경 사유는 단 하나입니다
클래스는 하나의 책임만 집니다. (책임: 변경 사유)
동일한 책임이 다른 클래스로 분산되는 것과 기능적 중복은 지양하세요

문제점

클래스에는 책임이 너무 많고, 여러 책임이 상호의존적입니다. 한 가지 책임이 변경되면 해당 클래스가 다른 책임을 수행하는 데 영향을 미치게 되며, 클래스 변경의 원인이 발생하면 예상치 못한 피해를 입게 됩니다

SPR 원칙 준수의 이점

클래스 간의 결합 감소: 요구 사항이 변경되면 하나의 클래스만 수정되므로 해당 변경 사항이 클래스의 다른 책임에 미치는 영향을 격리합니다
클래스 재사용 특징: 요청 시 참조, 하나의 클래스는 하나의 책임을 담당합니다. 요구 사항이 변경되면 해당 클래스를 수정하거나 특정 책임을 추가하면 됩니다.
클래스의 복잡성을 줄입니다: 단일 책임, 분산 기능 하나의 클래스에서 여러 클래스 수 줄이기 책임 클래스의 복잡성

코드 예

class ParseText
{
    private $content;
    
    public function decodeText(String $content)
    {
        // TODO: decode content
    }
    
    public function saveText()
    {
        // TODO:: save $this->content;
    }
}
/*
问题思考：
解析的文本类型会有多种-html、xml、json
保存的文本也会有多种途径-redis、mysql、file
客户端只需要解析文本时必须会引入saveText不需要的方法
两个职责之间没有强烈的依赖关系存在
任意职责需求变化都需要更改这个类
*/

/*
符合SRP的设计
职责拆分
*/

class Decoder
{
    private $content;
    
    public function decodeText(String $content)
    {
    // TODO: decode content
    }
    
    public function getText()
    {
        return $this->content;
    }
}

class Store
{
    public function save($content)
    {
        // TODE: save
    }
}

로그인 후 복사

Summary

소프트웨어 설계의 대부분은 책임을 발견하고 책임 간의 관계를 합리적으로 분리하는 것입니다. 애플리케이션 변경 사항이 항상 동시에 여러 책임에 영향을 미치는 경우 책임을 분리할 필요가 없습니다.

인터페이스 분리 원칙 ISP

문제

애플리케이션을 디자인할 때 클래스의 인터페이스가 응집력이 없습니다. 다양한 클라이언트에는 일부 중앙 집중식 기능만 포함되어 있지만 시스템은 클라이언트가 모듈의 모든 메소드를 구현하도록 강제하고 일부 멍청한 메소드도 작성합니다. 이러한 인터페이스는 뚱뚱한 인터페이스 또는 인터페이스 오염이 됩니다. 이러한 인터페이스는 시스템에 부적절한 동작을 도입하고, 리소스를 낭비하고, 다른 클라이언트 프로그램에 영향을 미치고, 결합을 향상시키는 등의 작업을 수행합니다.

ISP 정의/기능

고객에게 강요해서는 안 됩니다. 필요하지 않은 메서드/함수에 대한 측면 종속성
클래스에 대한 클래스의 종속성은 가장 작은 인터페이스를 기반으로 해야 합니다.
인터페이스의 구현 클래스는 단일 책임 원칙으로만 표시되어야 합니다

ISP 원칙을 따르세요. 장점

별도의 굵은 인터페이스, 각 인터페이스 그룹은 특정 클라이언트 프로그램 그룹을 제공하는 특정 기능을 제공합니다.
인터페이스 그룹에 대한 변경 사항은 다른 인터페이스/클라이언트에 영향을 미치지 않거나 약간의 영향을 미칩니다. 인터페이스의 순수성을 보장합니다

솔루션

팻 인터페이스는 여러 클라이언트별 인터페이스/다중 인터페이스로 분리된 상속으로 분해됩니다.
위임된 분리 인터페이스를 사용하면 두 개체가 동일한 요청 처리에 참여합니다. 요청을 수락하는 개체는 처리를 위해 요청을 다른 개체에 위임합니다

코드 예

/*
* 公告接口
*/
interface Employee
{
    public function startWork();
    public function endWork();
}

/*
* 定义特定客户端接口
*/
interface Coder
{
    public function writeCode();
}

interface Ui
{
    public function designPage();
}

class CoderClient implements Employee, Coder
{
    public function startWork()
    {
        //TODO:: start work time
    }
    public function endWork()
    {
        //TODO:: end work time
    }
    
    public function writeCode()
    {
        //TODO:: start write code
        return 'hellow world';
    }
}
$c = new CoderClient();
echo $c->writeCode();

로그인 후 복사

요약

Fat 클래스는 클라이언트 프로그램 간의 비정상적이고 유해한 결합 관계로 이어질 수 있습니다. 씩(thick) 클라이언트를 여러 클라이언트별 인터페이스로 분해함으로써 클라이언트는 실제로 호출하는 메서드에 긴밀하게 종속되므로 클라이언트와 호출하지 않는 메서드 간의 종속성을 제거합니다. 인터페이스 격리는 작고 드물게 유지되어야 합니다.

SRP와 ISP의 비교

둘 다 소프트웨어 설계의 종속성 해결 원칙에 기반합니다.
SRP는 책임 분할에 중점을 둡니다. 주요 제약 클래스는 실제로 세부 사항과 메서드입니다. 프로그램에서 구현. ISP는 인터페이스의 격리에 제약을 가합니다. 좀 더 거시적인 관점에서 인터페이스의 추상적인 디자인을 살펴보세요

Open-Close 원칙 OCP

Problems

소프트웨어 시스템의 규모가 계속해서 확장됩니다. , 시스템 유지 및 수정의 복잡성이 계속해서 증가하고 있습니다. 시스템의 한 부분이 변경되면 다른 모듈에 영향을 미치는 경우가 많습니다. OCP 원칙을 올바르게 적용하면 이러한 문제를 해결할 수 있습니다.

정의/특징

모듈은 동작 확장 측면에서 개방적이고 변경 가능성 측면에서 폐쇄적이어야 합니다.

OCP 장점을 따르세요

모듈의 동작은 확장 가능하고 편리할 수 있습니다. 동작 확장 /기존 모듈의 기능
모듈 동작의 확장은 기존 시스템/모듈에 영향을 미치지 않습니다/사소한 영향을 미치지 않습니다

코드 샘플

/*
* 定义有固定行为的抽象接口
*/
interface Process
{
    public function action(String $content);
}

/*
* 继承抽象接口，扩展不同的行为
*/
class WriteToCache implements Process
{
    public function action(String $content)
    {
        return 'write content to cache: '.$content;
    }
}

class ParseText
{
    private $content;
    public function decodeText($content)
    {
        $this->content = $content;
    }
    
    public function addAction(Process $process)
    {
        if ($process instanceof Process) {
            return $process->action($this->content);    
        }
    }
}

$p = new ParseText();
$p->decodeText('content');
echo $p->addAction(new WriteToCache());

로그인 후 복사

요약

OCP의 핵심 아이디어는 추상 인터페이스 프로그래밍, 추상화입니다. 비교적 안정적입니다. 클래스를 고정된 추상화에 의존하게 하고, 클래스가 객체지향 상속과 다형성을 통해 추상화를 상속하게 하고, 클래스의 메서드나 고유한 동작을 덮어쓰게 하는 것입니다. 이는 새로운 확장 메서드/함수를 생각하고 확장을 달성하는 것입니다.

里氏替换原则（Liskov Substitution Principle LSP）

问题

面向对象中大量的继承关系十分普遍和简单，这种继承规则是什么，最佳的继承层次的规则又是什么，怎样优雅的设计继承关系，子类能正确的对基类中的某些方法进行重新，这是LSP原则所要处理的问题。

定义/特性

子类必须能够替换掉他们的基类型：任何出现基类的地方都可以替换成子类并且客户端程序不会改变基类行为或者出现异常和错误，反之不行。
客户端程序只应该使用子类的抽象父类，这样可以实现动态绑定（php多态）

违反LSP原则

假设一个函数a，他的参数引用一个基类b，c是b的派生类，如果将c的对象作为b类型传递给a，会导致a出现错误的行为，那没c就违法了LSP原则。

/*
* 基类
*/
class Computer
{
    public function action($a, $b)
    {
        return $a+$b;
    }
}
/*
* 子类复习了父类方法，改变了action 的行为
* 违反了LSP原则
*/
class Client extends Computer
{
    public function action($a, $b)
    {
        return $a-$b;
    }  
}

function run(Computer $computer, $a, $b) {
    return $computer->action($a, $b);
}

echo run((new Client()), 3, 5);

로그인 후 복사

总结

LSP是OCP得以应用的最主要的原则之一，正是因为子类性的可替换行是的基类类型在无需修改的情况下扩展功能。

依赖倒置原则（Depend Inversion Principle DIP）

问题

软件开发设计中，总是倾向于创建一些高层模块依赖底层模块，底层模块更改时直接影响到高层模块，从而迫使他们改变。DIP原则描述了高层次模块怎样调用低层次模块。

定义/特性

高层模块不应该依赖与底层模块，二者都应该依赖于抽象
抽象不应该依赖与细节，细节应该依赖于抽象

代码示例

interface Arithmetic
{
    //public function sub($a, $b);
}

class Client
{
    
    public function computer(Arithmetic $arithmetic, $a, $b)
    {
        return $arithmetic->add($a, $b);
    }
}

class Addition implements Arithmetic
{
    public function add($a, $b)
    {
        return $a + $b;
    }
}

$c = new Client();
echo $c->computer(new Addition(), 2, 3);

/*
client 高层类 依赖于Arithmetic，Addition底层实现细节类实现Arithmetic接口，达到二者依赖于抽象接口的DIP设计原则
*/

로그인 후 복사