C# 인터페이스 분리 원칙의 예 혼란

Question

내가 프로그래밍 비교적 새로운 그리고 난 데 문제가 효과적으로 적용하는 방법을 이해하는 원리는 다음 링크 (현금 지급기 한)에서 나타났다 기본적으로 ISP (Interface Segregation Principle)에 불평하지 않는 디자인으로 시작하여 동작을 다른 인터페이스로 리팩토링하는 방향으로 나아갑니다.

내 질문 : 인터페이스를 사용하여 관련 추상화가 아닌 공통 동작을 표현하지 않습니까?

인터페이스에서 메소드를 캡슐화하는 것이 중요합니다. 인터페이스를 구현하려는 클래스와 공유되지 않는 경우도 있습니다. 이것이 어떤 시나리오에서 유용하다고 생각할 수 있습니까? 우리가 예를 들어 라인을 계속하면

은 다음 코드가 주어진다 :

public interface Transaction 
    { 
     void Execute(); 
    } 

    public interface DepositUI 
    { 
     void RequestDepositAmount(); 
    } 

    public class DepositTransaction : Transaction 
    { 
    private DepositUI depositUI; 
    public DepositTransaction(DepositUI ui) 
    { 
     depositUI = ui; 
    } 
    public virtual void Execute() 
    { /*code*/ 
     depositUI.RequestDepositAmount(); 
     /*code*/ } 
    } 

    public interface WithdrawalUI 
    { 
     void RequestWithdrawalAmount(); 
    } 
    public class WithdrawalTransaction : Transaction 
    { 
     private WithdrawalUI withdrawalUI; 
     public WithdrawalTransaction(WithdrawalUI ui) 
     { 
      withdrawalUI = ui; 
     } 
     public virtual void Execute() 
     { /*code*/ 
      withdrawalUI.RequestWithdrawalAmount(); /*code*/ 
     } 
    } 
    public interface TransferUI 
    { 
     void RequestTransferAmount(); 
    } 
    public class TransferTransaction : Transaction 
    { 
     private TransferUI transferUI; 
     public TransferTransaction(TransferUI ui) 
     { 
      transferUI = ui; 
     } 
     public virtual void Execute() 
     { /*code*/ 
      transferUI.RequestTransferAmount(); 
      /*code*/ 
    } 
    public interface UI : DepositUI, WithdrawalUI, TransferUI { } 

지금까지 내가 이것을 이해로, 이전 디자인을 사용하기 위해 우리가해야 뭔가 같은 :

UI impui = new IMPLEMENTATIONUI(); // Some UI implementation 
DepositTransaction dt = new DepositTransaction(Gui); 
dt.Execute(); 

이제 IMPLEMENTATIONUI가 모든 단일 메소드를 구현할 필요가 없습니까? 그렇다면 SRP를 깨뜨리지 않을까요?

Answer 1

인터페이스를 사용하여 관련 추상화가 아닌 공통 동작을 표현하지 않습니까?

예, SOLID에서 인터페이스는 공통적 인 동작을 나타내야합니다. 거래 인터페이스는 이것의 훌륭한 예입니다. DepositTransaction 클래스와 WithdrawlTransaction 클래스는 모두이 클래스에 의존합니다. ISP (Interface Segregation Principle)는 트랜잭션 객체를 실행하기위한 함수에 전달해야 할 필요가 있기 때문에이를 분리해야합니다. 모든 솔리드 원칙은 디자인입니다. 예 :

void ExecuteTransaction(Transaction transaction) 
{ 
    transaction.Execute(); 
} 

이 방법은 트랜잭션 인터페이스 이외의 다른 요소가 아닙니다. 이것은 종속성 반전입니다.

이 인터페이스를 만들지 않으면 WithdrawlTransaction 또는 DepositTransaction을 실행하기위한 두 가지 다른 메소드를 만들어야합니다. 대신 ExecuteTransaction 메서드를 사용하고 Transaction을 구현하는 모든 것을 전달할 수 있습니다.

ExecuteTransation(withdrawl_TransactionObject); 

또는 미래에

ExecuteTransaction(deposit_TransactionObject); 

이상 : 이제

ExecuteTransaction(unanticipatedNewTypeOf_TransactionObject); 

, 우리는 IMPLEMENTATIONUI 매 메소드를 구현하는 것이 필요하지 않을까요? 그렇다면 SRP를 깨뜨리지 않을까요?

구현 UI는 아마도 사용자가 소프트웨어와 상호 작용하는 데 사용하는 것입니다. 사용자는 단일 책임을 가지지 않으므로 이론적으로 사용자는 IMPLEMENTATIONUI 클래스에 필요한 모든 인터페이스를 사용해야합니다.

나는 UI가 인터페이스의을 모두 구현하는 것이 구현을 의심하지만 트랜잭션을 실행하기 위해 가능성이 사용 이러한 인터페이스의 모든 것. "삼촌 Bob"을 바꿔 말하면 Solid Principles 사용자 인터페이스는 휘발성 코드로 가득 차 있어야하며 인터페이스는 가장 비 휘발성이어야합니다.