7주차에 와서야 6주차 WIL을 작성하지만, 그만큼 한것도 많고, 바빴던것 같다. 그 사이에 다양한 것을 배웠고, 인터페이스 위주 개발을 시도한 이력이 있어 이에 대해 한번 집고 넘어가기 위해서 늦었지만 6주차 WIL을 추가적으로 작성한다.
인터페이스 지향적 사고
인터페이스 지향적 사고가 필요한 이유
우선 지금까지 해왔던 객체 지향적 사고에 대해 다시 생각해보자. 나름 상속이라는것을 받으며 작업을 진행하지만, 결국 몇가지 문제점이 있다.
- class 객체는 하나만 상속이 가능하다
- 여러명이 협업을 하다보면, 서로 중복되는 메소드들도 생길 수 있으며, 작업시 conflict가 날 가능성도 존재한다.
6주차에 설명을 들었던 bridge와 TemplateMethod 디자인 (사실 둘은 거의 비슷하다.)을 사용한다면 이를 충분히 해결 해 줄 수 있다. 우선 인터페이스 지향적 사고를 어떻게 해야 할 지부터 생각해보자.
인터페이스 사용 이유
우선 인터페이스의장점은 여러가지가 있지만, 간단하게 집고 넘어가자.
우선 다중상속이 가능하다. 어찌보면 모듈식으로 레고처럼 조립이 쉽다는 뜻이다.
또한 인터페이스를 상속받을 시 인터페이스 내부의 기능들을 모두 포함해야 하기 때문에, 중복되는 메소드가 줄어들 것이고, 다른 사람들이 작업 한 내용을 보고 참고하여 작업 또한 가능하다.
마지막으로, Conflict가능성이 낮아지는데, 이는 인터페이스 구조를 어떻게 짜는지 보면서 보도록 하자.
인터페이스 사용 방식
6주차에 했던 개인 과제를 진행 할 시 TemplateMethod와 Bridge 패턴을 사용하여 작업을 했다. 우선 순서를 생각해보면 다음과 같다.
- 클래스 다이어그램을 짤 시 중복되는 메서드가 필요하다면, 이를 인터페이스로 빼 둔다. (중복이 한 부류에 속하다면 abstract class로 빼 둬도 무관하다)
- 이 인터페이스들을 따로 개인적으로 처리해 필요한 스크립트들을 만든다.
- 이 스크립트들을 하나의 컴포넌트에 붙여서 참조한다.
일단 이 설명만 들으면 직관적이지 않으니 하나를 보도록 하자.
우선 이것은 아이템 중 하나이다. 보면 ItemObject라는 스크립트와, AddDamage, AddSpeed라는 스크립트가 붙어있다.
이 때 ItemObject는 실제 물체를 설명하는 스크립트이다.
반면 AddDamage와 AddSpeed는 인터페이스가 달려있는 기능들 구현부이다.
AddSpeed와 AddDamage는 IUsable을 상속받고, 이 인터페이스는 사용가능한 기능들에 달려있으면 된다. 나중에 우리가 점프력을 100늘려주는 기능이 있다면 IUseable을 상속 받고, 해당 스크립트의 기능만 따로 만들어주면 된다는 것이다.
이제 우리가 필요한 기능들이, 즉 사용 될 시점에, 해당 오브젝트에 있는 IUseable컴포넌트들을 가져와 사용만 해 주면된다.
즉 우리가 이 아이템에 AddDamage를 넣어주면 이 오브젝트가 사용될때 데미지를 줄것이고, 기능들을 넣어주는대로 자동으로 기능들이 실행되는 것이다.
이는 따로 스크립트로 만들어서 레고블럭처럼 조립하기도 쉽다. 예를들면 다른 오브젝트가 있다고 했을 때, 같은 속도 증가 기능을 사용한다면, 그저 AddSpeed를 그 오브젝트에 달아주면 되는 것이다.
즉 아까 위에서 말한 conflict가 나지 않는다는 부분도 이 부분에서 생겨난다. 만약 class 오브젝트에 새로운 기능이 생겼다고 해보자. (예를들면 힐을 해주는 기능과 점프력을 늘려주는 기능도 생겼다고 하자.)
그러면 그 클래스 내부에서 두사람이 따로 작업을 인터페이스를 상속 받아 할 수 있는 것이다. (한사람은 힐을, 다른 사람은 점프력을 늘려주는 스크립트 작성)
반면 이를 다르게 접근하는 방법도 있다.
상속을 받지 않고 변수로 들어간 인터페이스
우선 플레이어 스크립트의 일부를 잠깐 보도록 하자.
여기서는 IGrab이라는 인터페이스가 따로 존재한다. 이는 해당 플레이어가 IGrab을 가질 수 있다는 것이다.
이 시점에서 IGrab을 플레이어 내부에서 구현하지 않고, 따로 두고 싶을 가능성이 있다. (플레이어는 보이기만 한 틀이지, 실제 코드들을 분리시키고 싶을때)
이럴때는 클래스들을 변수들로 넣어주는것처럼 인터페이스 또한 넣어줄 수 있다는 것이다.
해당 인터페이스는 물론 따로 가지고 간 스크립트 내부에서 구현을 해 줄 필요는 있다. 하지만 이렇게 구현하게 된다면, 훨씬 간결해지고, 한곳에 뭉쳐 있을 필요도 없으며, 다른곳에서도 쓰게 된다면 확장 또한 가능 한 점이 인터페이스의 장점이라고 보면 된다.
인터페이스의 주의점
인터페이스에도 주의점이 몇가지 있다. 대충 인터페이스 남용을 줄여보면 된다.
- 하나만 있는것은 class에서 처리해주면 된다. 인터페이스가 너무 많을 필요 없다는 소리다.
- 하나의 부류에서만 사용 될 가능성이 있다면, 이 또한 abstract클래스로 처리 해 주면 좋다.
그리고 협업을 하면서 몇가지 발견된 문제도 있을 수 있다.
3. 인터페이스의 변수를 바꾸고 싶을때 함부로 못바꾼다.
현 7주차에 작업을 하다 발견된 문제이지만, 이를 해결하는 협업 방식은 다음과 같다.
- 인터페이스를 한사람이 하나 맡아서 제작할것
예를들면 한사람은 이동하는 IMoveable관리, 다른사람은 잡을 수 있는 IGrab관리 - 이렇게 하면 한사람이 인터페이스 하나를 맡아 수정을 하기 수월 할 것이다.
마무리
일단 인터페이스 위주의 작업을 해본 내용들은 해당 깃허브를 공유 해 드리겠다. 물론 여러 트러블 슈팅들도 있었지만, 이는 git의 readme 또한 작성 해 두었으니, 참고하길 바란다.
이번에 인터페이스 작업을 하며 여러모로 구조적 설계를 하는 실력이 늘은 듯 하다.
[주차 git]
