유니티 C#에서 is-a관계? has-a 관계? 그리고 can-do관계?

상속과 구현

 

상속이랑 인터페이스를 다루다 보니 is-a나 can-do 관계를 알게되었습니다.

 

이런거 왜 구분시키나 했는데 내가 개발할 대상이 is-a 상황인지 can-do 상황인지 따지면 상속 쓸지 인터페이스 쓸지 쉽게 결정이 가능합니다.

 

한번 가볍게 알아봅시다.

---

#1 is-a 관계 (Is-A Relationship)

is-a 관계

 

is-a가 되면 상속을 할 수 있습니다.

NPC도 사람이고 나도 사람이니 사람을 상속할 수 있습니다.

추상 클래스에서 쓰이고 당연하게도 상속관계를 나누면 위에 갈수록 일반적이고 큰 개념,

아래 갈수록 구체적이고 작은 개념이 됩니다.

 

C#의 클래스에서는 is-a 관계 : 한 클래스가 다른 클래스의 생(자식) 클래스라는 아주 긴밀한 관계

비유로는 is-a 관계는 부모의 유전을 그대로 받아 태어납니다.

단점도 있는데 긴밀하기에 부모가 손상되면 자식도 손상이 됩니다.

---

#2 has-a 관계 (Has-A RelationShip)

has a 관계

상속이라고 하긴 애매하고 다른 스크립트에 있는 클래스를 참조해서 가져오는 걸 has-a 관계라고 합니다.

유니티 쓰면서 코드에 자주 사용하는 Animator도 이런 느낌입니다.

 

public class Player : MonoBehaviour
{
    private Animator animator; //플레이어는 애니메이터를 가진다
}

보통은 이렇게 씁니다.

public class Player : MonoBehaviour
{
    public Gun gun; //플레이어는 총을 가진다
    private Animator anim; //플레이어는 애니메이터를 가진다
    
    private void Awake()
    {
    	gun = new Gun(); //객체 선언(총을 준다)
    }
}

 

아까 is-a 관계는 긴밀해서 손상 위험이 크다고 했는데

has-a 관계는 조금 더 느슨하기에 손상 위험이 상대적으로 더 적습니다.

---

#3 can-do 관계 (Can-Do RelationShip)

can do 관계

can-do 관계 : 대상 클래스가 할 수 있다는걸 명시하는 관계

비유로는 can-do 관계는 부모의 유전과 상관없이 후천적으로 무언가를 할줄 알게 되는겁니다.

그렇기에 인터페이스 같이 후천적으로 기능을 구현을 하는겁니다.

그리고 NPC같이 대화 가능한 애들은 Talk() 메서드(함수)를 구현하라고 강제할 수 있습니다.

대화뿐 아니라 걷고 뛰고 등등 여러개 상속이 필요하니 인터페이스가 필요한 겁니다.