19. php: The Right Way - S.O.L.I.D

해당 글은 PHP : The Right Way 를 참고하였다.

 

1. SRP - 단일 책임원칙

 - '클래스는 한가지의 이류로만 변경되어야 한다.'라는 내용. 이는 모든 클래스가 한가지의 기능만 가져야 한다는 것을 의미한다. 이 접근법의 가장 큰 이점은 코드 재사용성을 향상 시킬수 있다는 점이다. 클래스를 한가지만 기능하도록 설계함으로써, 다른 어떤 프로그램에서도 이 클래스를 사용할 수 있다.

 

2. OCP - 개방/폐쇄(Open/Closed)의 원칙

- ' 소프트웨어(클래스, 모듈, 함수 등)는 확장을 위해 열려 있어야 하지만 수정을 위해 닫혀 있어야 한다.' 

예를 통해 알아보자.

class Dog{
	public function bark(): String
    {
    	return '왈왈';
    }
}

class Duck
{
	public function quack(): string
    {
    	return '꽥 꽥';
    }
}

class Cat
{
    public function whatDoesTheCatSay(): string
    {
        return '야 옹';
    }
}

그리고 동물들이 서로 의사소통을 할 수 있는 class

class Communication
{
    public function communicate($animal): string
    {
        switch (true) {
            case $animal instanceof Dog:
                return $animal->bark();
            case $animal instanceof Duck:
                return $animal->quack();
            case $animal instanceof Cat:
                return $animal->whatDoesTheCatSay();
            default:
                throw new \InvalidArgumentException('Unknown animal');
        }
    }
}

여기서 질문 Communication 클래스는 수정하지 않고 새로운 동물을 추가할 수 있나요?? 없습니다. 새로운 동물을 추가하기 위해서는 코드를 수정해야 합니다. 좀더 OCP 원칙에 맞게 코드를 수정해 보자.

interface Communicate
{
	public function speak() : String
}

Class Dog implements Communicate
{
	public function speak():string
    {
    	return '왈왈';
    }
}

Class Duck implements Communicate
{
	public function speak()
    {
    	return '꽥꽥';
    }
}

Class Cat implements Communicate
{
	public function speak()
    {
    	return '야옹';
    }
}

Class Communication
{
	public function Communicative (Communicate $animal)
    {
    	return $animal->speak();
    }
}

코드를 사용할 때 인터페이스를 사용함으로써 코드를 간결하게 할 수 있고 미래에 변화를 할때 수정을 가할 필요가 없이 클래스에 한가지의 기능만을 가지게 할 수 있다. 새로운 응답형식이나 추가 매개변수와 같이 향후 변경이 필요한지 여부도 고려해야 하며 수정을 위해 코드를 닫아야 한다.

 

3. LSP - 리스코프 치환의 원칙

 - '하위모듈은 언제나 상위 모듈로 교체할 수 있어야 한다.' ,'하위모듈은 상위모듈과 호환될 수 있어야 한다. 하위모듈은 상위모듈이 약속한 규약(public 인터페이스, 메소드)을 지켜야한다.'

1. 두 개체가 똑같은 일을 한다면 둘을 하나의 클래스로 표현하고 이들을 구분할 수 있는 필드를 만든다.

2. 똑같은 연산을 제공하지만, 이들을 약간씩 다르게 한다면 공통의 인터페이스를 만들고 둘이 이를 구현한다.(인터페이스 상속)

3. 공통된 연산이 없다면 완전별개인 2개의 클래스를 만든다.

4. 만약 두 개체가 하는 일에 추가적으로 무언가를 더 한다면 구현상속(부모클래스 상속)을 사용

 

4. ISP - 인터페이스 분리의 원칙

범용성 있는 하나의 인터페이스보다 작업별로 나뉘어 있는 세부적인 인터페이스를 사용하자.

 

5. DIP - 의존성 역전의 원칙

1. 상위 모듈(인터페이스, 클래스)은 하위 모듈(클래스)에 의존해서는 안된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다.

2. 추상화는 세부 사항에 의존해서는 안된다. 세부사항이 추상화에 의존해야 한다.

 

구조적 디자인에서 발생하던 하위 레벨 모듈의 변경이 상위 레벨 모듈의 변경을 요구하는 위계관계를 끊는 의미의 역전이다. 실제 사용관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고받음으로써 관계를 최대한 느슨하게 만드는 원칙

 

'직접 상속하는 것이 아니라 사이에 추상계층을 만들어 둘사이를 연결하고 메시지를 주고받는다.'