배고파서 잠이 안온다...
디씨에 글 처음 싸보는데 심지어 모바일로 쓰고 있어서 읽기 힘들어도 이해 바란다
주제는 "매개변수를 받지 않고 값을 반환하지 않는 메소드"의 사용이다.
게임프로그래밍의 중요한 특징으로 사전설계의 어려움을 꼽고싶다.
어떤 기획이 추가/변경/제거될 것인지 예측하기 힘들다는 것은 여러분이 모두 잘 아실듯.
따라서 게임코드는 기획의 변경에 따라 진화(보통은 퇴화..)한다.
(이 부분은 지속적인 리팩토링을 통해 어느정도 방어가 가능하나 너무 많은 시간을 투자할 경우 새로운 기능을 추가할 시간을 잃게 된다.)
코드의 변경을 방해하는 대표적인 것은 복잡한 의존관계이다.
어떤 클래스를 통째로 변경해야한다고 하자.
이 때 해당 클래스에 대한 의존성이 코드베이스 전체에 산재한다면, 보통 말하는 "차라리 처음부터 다시 짜자"와 같은 상황이 발생한다.
따라서 코드베이스의 변경에 대한 유연성을 확보하려면 타입 간의 상호 의존을 줄일 필요가 있다.
일반적으로 타입 의존성 관계를 복잡하게 만드는 주범은 매개변수와 반환이다.
매개변수는 의존성의 입력을 의미하며 반환은 의존성의 출력을 의미한다.
이러한 관점에서 볼 때, 매개변수와 반환의 사용을 의도적으로 줄일 경우 매우 간결한 의존관계를 디자인할 수 있다.
하지만 매개변수와 반환없이 어떻게 서로 다른 클래스의 상호작용을 설계할 수 있냐는 의문이 남는다.
이에 대한 해답은 자신이 작성 중인 코드가 매개변수와 반환을 최대한 적게 사용하도록 바꿔보며 찾아보길 바란다.
다음 배고픈 새벽에 만나요~
사족.
타입 의존성을 줄이기 위해 '일반적'으로 사용하는 방법은 구체클래스 대신에 인터페이스에 의존하도록 설계하는 것이다.
디씨에 글 처음 싸보는데 심지어 모바일로 쓰고 있어서 읽기 힘들어도 이해 바란다
주제는 "매개변수를 받지 않고 값을 반환하지 않는 메소드"의 사용이다.
게임프로그래밍의 중요한 특징으로 사전설계의 어려움을 꼽고싶다.
어떤 기획이 추가/변경/제거될 것인지 예측하기 힘들다는 것은 여러분이 모두 잘 아실듯.
따라서 게임코드는 기획의 변경에 따라 진화(보통은 퇴화..)한다.
(이 부분은 지속적인 리팩토링을 통해 어느정도 방어가 가능하나 너무 많은 시간을 투자할 경우 새로운 기능을 추가할 시간을 잃게 된다.)
코드의 변경을 방해하는 대표적인 것은 복잡한 의존관계이다.
어떤 클래스를 통째로 변경해야한다고 하자.
이 때 해당 클래스에 대한 의존성이 코드베이스 전체에 산재한다면, 보통 말하는 "차라리 처음부터 다시 짜자"와 같은 상황이 발생한다.
따라서 코드베이스의 변경에 대한 유연성을 확보하려면 타입 간의 상호 의존을 줄일 필요가 있다.
일반적으로 타입 의존성 관계를 복잡하게 만드는 주범은 매개변수와 반환이다.
매개변수는 의존성의 입력을 의미하며 반환은 의존성의 출력을 의미한다.
이러한 관점에서 볼 때, 매개변수와 반환의 사용을 의도적으로 줄일 경우 매우 간결한 의존관계를 디자인할 수 있다.
하지만 매개변수와 반환없이 어떻게 서로 다른 클래스의 상호작용을 설계할 수 있냐는 의문이 남는다.
이에 대한 해답은 자신이 작성 중인 코드가 매개변수와 반환을 최대한 적게 사용하도록 바꿔보며 찾아보길 바란다.
다음 배고픈 새벽에 만나요~
사족.
타입 의존성을 줄이기 위해 '일반적'으로 사용하는 방법은 구체클래스 대신에 인터페이스에 의존하도록 설계하는 것이다.
- dc official App
이런말 처음엔 하나도 이해 안됐는데 할수록 이해가 되더라... 직접 삽질 하지 않으면 와닿지가 않는듯
사족이 핵심임.
알려줄거면 아예 넉넉히좀 알려줘요.. 초보 플머인 저 같은 사람은 애가 타 죽습니다.
1. 파라미터와 리턴값이 없는 함수의 경우 입출력(파라미터 역할을 할 변수를 가져오거나 결과를 어디에 저장하거나)을 함수 내부에서 한다는건 데, 그걸 사이드 이펙트라고 하는거 아님? 사이드 이펙트가 많은 코드는 디버깅 하기가 어렵다고 들어서 지양해야 한다고 알고있었는데, 그렇지가 않은건가요 아니면, 대처방법이 있는 거임 아니면, 그걸 감수하고라도 할 만큼 의존관계 해소가 중요하다는거임?
2.매개변수와 반환 없이 상호작용하는 방법이 .. 제수준에서 떠오르는 건 싱글톤을 사용하거나, 야매로 전역변수 비스무리한 역할을 하는 큐같은걸 만들어서 입/출력을 해소하는 건데, 막상 플밍을 해보니까 두 방법 모두, 얘는 사용자 입력용큐, 얘는 입력데이터를 게임내 이벤트로 전환시켜놓은거 큐 -> 게임내 이벤트를 로직으로 저장할데이터, 재생되어야될 이펙트 큐, 모션큐 막 이런식으로 가짓수가 폭증하던데 너무 난잡하게 느껴집니다. ( 싱글톤으로 하는경우에도 마찬가지 ) 이게 정상인가요 아니면 제가 할줄모르는거?
매개변수와 반환을 사용하지 않았을때 상당한 이득이 있는 예를 하나 들어줬으면 좋겠습니다. 그럼 ㄳ
이런 설계방법론에 대한 문제는 고민해볼수록 결국 점점 더 나은 설계를 할수 있게 되는건 맞지만... 궁극적으로는 은탄환은 없다는 단순한 진리에 도달함
hong 다음 주제로 다룰 수 있도록 해보겠습니다ㅎㅎ 새우맨 만렙ㅊㅋ - dc App
분명 더 나은설계 원칙들은 존재하지만 현실적으로 케바케랄까.. 모든 곳에 들어맞는 해법은 이것이다! 이런게 없죠... (그렇다고 이런 고민이나 글쓴분이 하려는 얘기가 의미없단 이야기는 아님)
헉 주워들은걸로 너무 아는척햇다... 다음편 기대합니다
오오! 다음편 기대합니다 ㄳ
ㄳㄳ