모던 C++ 디자인 패턴 : 인터페이스 분리 원칙(Interface Segregation Principle, ISP)
필요한 인터페이스만 구현할 수 있도록!..
SOLID 원칙으로 유명한 인터페이스 분리 원칙(Interface Segregation Principle) ISP에 대해서 알아보자.
인터페이스 모든 항목에 대해 구현을 강제하지 않아야 한다. 필요한 인터페이스만 구현할 수 있도록 설계하는 것을 말한다.
인터페이스 모든 항목에 대하여 구현을 강제하지 않는다는 것은 무엇을 말할까? 아래의 모 블로그 포스트의 사진을 보자.
사진과 같은 헤드셋이 있다고 생각해보자. 아날로그, 2.1채널, HDMI… 내가 쓸지 안쓸지도 모르는 규격의 케이블을 모두 포함되어 있어서 좋다고 해야할까? 자주 쓰는 단 하나의 규격만을 포함하고 있고, 나중에 다른 규격이 필요하면 어댑터를 사서 사용하는 것이 더 좋지 않을까?
이런 경우처럼, 반드시 필요한 인터페이스만 구현할 수 있도록 목적 단위로 인터페이스를 분리하여 구현하는 것을 인터페이스 분리 원칙이라 한다.
목적 단위의 인터페이스 구현
구현된 C++ 예를 통해 알아보자.
위처럼 MultiFunctionPrinter를 구현하던 중, 이후 추가될 클래스들을 위해 IMachine인터페이스 클래스를 구현했다고 생각해보자. MultiFunctionPrinter는 프린트도 되고, 팩스도 되고, 스캔도 되니까 세 가지 기능을 가상함수로 미리 정의해두었다. 이제 인터페이스가 필요한 또 다른 클래스를 추가 시 IMachine을 상속 받기만하면 된다.
Scanner라는 클래스를 추가했다. IMachine 인터페이스 클래스를 상속 받고 보니, Scanner 에서는 필요하지 않은 print(), fax() 함수들이 있다. 이런 경우, 필요하지 않더라도 인터페이스 클래스에서 정의된 메소드들을 모두 다시 구현해야 한다.
이제 목적 단위로 인터페이스를 분리해서 구현해보자.
인터페이스 정의부부터 보면, 목적 단위로 인터페이스 클래스를 별도로 두고 있다. 프린트, 스캔, 팩스는 각 IPrinter , IScanner , IFaxer 로 정의하였고 이제 Printer, Scanner, Faxer 와 같은 클래스들은 필요한 인터페이스들만 상속 받아 구현하면 된다.
예로, IMachine 은 세 가지 인터페이스를 모두 상속 받았으며, 상속 받은 인터페이스 함수들을 메소드에 오버라이딩하여 재구현하였다.
인터페이스 분리 원칙을 잘 지켜 구현한다면 재사용성이 높아지고, 변경에 더욱 용이하다.
