유니티 - 대체 인터페이스를 왜 쓰는걸까?

인터페이스라 하면 공통적인 동작을 정의해 두는 것이고 추상화가 가능하고 다중 상속이 가능하고 상속 시 반드시 구현해야한다는 강제성을 가지고 있다.

 

사실 이렇게만 들으면 대체 왜 쓰는 지 감이 잡히질 않는다.

 

객체지향적인 코드를 짜려면

 

우리는 클래스 간의 의존도를 낮춰 결합도를 낮춰야한다.

 

클래스 간의 의존도가 높게 되면 다른 사람이 어떤 클래스를 수정시에 내가 만든 클래스를 수정하게 될 수도 있다. 즉 다른 하나를 수정하면 남이 만든 다른 클래스도 건들일 수 있다는 것이다.

 

그렇기에 결합도는 낮추고 코드 내의 응집도를 높여야 한다는 것이다.

 

응집도를 높이려면 코드 내의 기능들이 그 코드안에서 수행되고 끝날 수 있도록 해줘야한다.

 

그렇기에 구체적인 클래스를 상속받는 것이 아닌 기능 별로 쪼갠 인터페이스를 상속을 받자는 것이다.

 

코드의 결합도를 낮추고 유연성을 높이기 때문에 협업의 관점서는 개발기간을 단축할 수 있다는 장점이 있다.

 

만일 결제 시스템이 있다고 해보자 

 

결제 방법에는 카드도 있고 현금도 있고 QR 코드의 방식도 있을 것이다. 

 

만일 이 결제 방법에 대한 것을 전부 클래스로 만든다면 

 

상점 코드를 짠다면 이 모든 결제 방법에 대한 정보를 담아둘 준비를 해야하고 if문을 통해 결제 방식이 무엇인지 비교를 해야하는 번거로움이 생긴다.

 

허나 인터페이스를 통해 만들어보자

 

그냥 Payment라는 인터페이스를 만들고 결제를 하는 Pay 함수를 두면 이를 상속받은 애들이 Pay함수를 반드시 구현을 해둘 것이다.

 

그러면 상점 코드에선 그냥 인터페이스 변수를 선언해두고 Payment payment;를 두고 payment.Pay()로 호출하면 끝난다.

 

클래스 간의 의존도도 떨어지는 것을 바로 확인할 수가 있다는 것이다.