이게 사실 게임 쪽에서만 쓰이는게 아니라 oop 상속 우회전략인데
이거가지고 설계할때 머리 아파하는 사람이 있더라고
근데 그거 oop를 잘못배워서 그래
oop 배운애들이 설계할때 꼭 명사부터 설계해
데이터를 범주화 해놓고 개발해야 한다고 생각하는거지
이건 oop에서 object가 타입이기도한 특성때문에 그런건데
타입을 정해놔야 연산이 정해진다고 보는 거거든
근데 그런 생각부터 틀렸다
모든 문제해결의 방법은 동사부터 정하는거다
oop의 핵심은 오브젝트가 아니라 메소드야
시나리오에 적합한 메소드를 생각해보니 이런 오브젝트가 있어야겠네 하는거지
시나리오없이 오브젝트 만들고 메소드 만들면 대부분 get/set밖에 못만든다
ecs도 마찬가지야
동작을 위한 system이 먼저고 그다음이 entity. 마지막이 component야
꼭 component먼저 정하려고 하다가 머리 과부화되서 다 꼬인다
사과 하나 더하기 사과라는 문제를 낼때 핵심은 사과가 아니라 더하기야
더하기를 정의하는데 사과가 타입인지 데이터인지 생각해봐야하는건 더하기라는 걸 정하고 난 다음이야
사과를 데이터로 정의했는데 타입이어야하면 다 뜯어고쳐야 하는거고 그 반대도 마찬가지.
설계할때 component먼저 정해야 좋을때도 있긴하다
전체 설계구조가 머리속에 다 들어가있고 무엇을 만들지 명확할때
기본적인 부품부터 만드는건 기본이지
근데 f35만들지 b2만들지 모르면서 나사 치수부터 정하는건 정상이 아니야