인터페이스 분리 원칙을 사용하는 것이 실용적입니까?

SOLID는 프로그래밍에서 매우 인기 있는 디자인 개념입니다. 인터페이스 분리는 SOLID 설계의 일부입니다. SOLID가 무엇인지 물어볼 수 있습니다.

SOLID are 5 software development principles or guidelines based on Object-Oriented design making it easier for you to make your projects scalable and maintainable.

코드에는 모범 사례와 규칙이 있습니다. SOLID 설계는 모범 사례와 같습니다.

인터페이스 분리

그것은 말한다

Clients Should Not Be Forced To Depend Upon Interfaces That They Do Not Use.

꽤 직설적 인.

이게 무슨 뜻이야

✔️ 더 작고 구체적인 인터페이스(역할 인터페이스)를 만듭니다.
❌ 클래스는 사용하지 않는 인터페이스를 구현할 수 있습니다.

왜 이러는 거지?

고려하다

A client depends upon a class that contains interfaces the client does not use, but other clients do use, then the first client will be affected by the changes other clients force upon the class used by the first client.

이 원칙의 목표는 이러한 상황을 피하는 것입니다.

및 와 같은 다른 SOLID 원칙의 패턴은 매우 유사합니다. 장기적으로 코드 손상을 방지합니다.

간단한 사용 사례

Bird 예제를 사용하면 에서 논의된 것과 매우 유사합니다.

interface Bird {
  fly(): void;
  walk(): void;
}

class Duck extends Bird{
    fly(){
        // Duck can fly
    }   
    walk(){
        // Duck can walk
    }
}

class Ostrich extends Bird{
    fly(){
        // Ostrich cant fly... throw some error
    }   
    walk(){
        // Ostrich can walk
    }
} 

여기서 fly()는 Duck 클래스에 의해 Ostrich 클래스에 적용됩니다. 둘 다 동일한 인터페이스를 구현하고 Duck이 fly()를 사용하기 때문입니다. 인터페이스 분리 원칙을 명백히 위반한 것입니다.


인터페이스 분리 원칙을 사용하여 코드를 다음과 같이 리팩토링합니다.

interface BirdFly{
    fly(): void;
}

interface BirdWalk{
    walk(): void;
}

class Duck extends BirdFly, BirdWalk{
    fly(){
        // Duck can fly
    }   
    walk(){
        // Duck can walk
    }
}

class Ostrich extends BirdWalk{
    walk(){
        // Ostrich can walk
    }
} 

우리는 이제 역할별 인터페이스를 만들었고 의도하지 않은 결합이 없습니다.

실용적입니까?

확실히, 가능할 때마다 이 원칙을 따르는 것이 가장 좋습니다. 그러나 요구 사항이 충족되고 우발적인 결합 문제를 해결할 수 있다면 이 원칙을 피할 수 있습니다.


인터페이스 분리를 ​​사용합니까? 의견에 귀하의 의견을 알려주십시오.

무엇 향후 계획

원칙을 사용할 가치가 있는 이유.