[클린소프트웨어#8] SOLID-인터페이스 분리 원칙(Interface Segregation Principle)

[클린소프트웨어#7] SOLID-의존 관계 연적 원칙(Dependency Inversion Principle)

 

# SOLID

• SRP (Single Responsibility Principle) 단일 책임 원칙
• OCP (Open Closed Principle) 개방 폐쇄 원칙
• LSP (Liskov Substitution Principle) 리스코프 치환 원칙
• ISP (Interface Segregation Principle) 인터페이스 분리 원칙
• DIP (Dependency Inversion Principle) 의존 역전 원칙

 

# 인터페이스 분리 원칙(Interface Segregation Principle)

 인터페이스 분리 원칙은 SOLID원칙 중에서 그나마 가장 이해하기가 수월 할 것이다. 클래스가 커질 수록 클라이언트들 간에 좋지 않은 결합도가 생기기 마련이다. 만일 이렇게 비대해진 클래스에 변경이 가해진다면, 이와 결합된 여러 클래스들에 영향을 끼치게 될 것이다. 핵심은 클라이언트는 자신이 실제로 호출하는 메소드에만 의존해야 한다는 것이다. 클래스의 인터페이스를 클라이언트 고유의 인터페이스 여러개로 분해하여 결합도를 낮춰야 한다.

 

# ATM 사용 예제

ATM에는 현금 입금, 인출, 이체등 여러 Transcation을 지원해야 한다. 그리고 이러한 Excute이 될 때마다 UI에 새로운 화면이 그려져야 한다.

UI을 그려주는 ATM UI라는 인터페이스를 각기의 UI에 구현함으로써 해결 할 수 있다.

그렇다면, 입금,인출,이체등의 행위로 UI와 어떻게 상호작용이 되어야 할까? 먼저 그다지 좋지 않은 해결책을 봐보자.

Deposit, Withdraw,Transfer는 Excute()에 대해서 어떠한 행위를 할 것이다. 그리고 나서는 UI를 업데이트하기 위해 UI인터페이스에 의존한다. 

class DepositTransaction {
	private UI ui;
    
    @override
    public void excute(){
    	// 입금을 수행함....
        ui.RequestDepositAmout()
    }
}

그러나 DepositTransaction에서는 사용하지 않는 RequestWitdrawalAmout(), RequestTransferAmout(),InformInsufficientFunds()가 존재하고, 만일 새로운 Transcation이 추가되면 UI인터페이스를 수정해야하고 그에 의존하는 다른 Transcation들이 재 컴파일 되어야 한다. 이런 일을 막기 위해서 UI인터페이스를 분리해야한다. 각 클라이언트에서 사용하는 인터페으들만으로 말이다.

 각 Transaction은 자신을 위한 특정 UI버전에 대해서는 알고 있어야한다. 그러나 전체에 대해서는 알 필요가 없다.