수다닷컴

그리고 제 생각에는 위의 예에서 Box 객체에서 Block 객체를 제어하는 것보다는 Box의 Owner 객체(이 겨우는 SetGame) 가 Block를 제어하도록 일종의 캡슐화하는 게 좋아보입니다.
즉, Block 클래스에 action() 메소드가 정의 되어 있다면 SetGame 클래스에서도 Block_Action() 메소드(혹은 잘 알아볼수 있는 메소드명)를 정의해서 이놈이 Block.action() 을 콜하도록 하는 것이 Box가 직접 Block에

static 을 많이 쓴다고 나쁠 건 없다고 봅니다. 필요할 때 쓰라고 만들어준 것일테니까요.(매클미뎌 땡쓰~) 다만 너무 많이 쓸 경우 오히려 구조적이지 못하거나 알아보기 힘들게 될 수도 있죠.
전 필요한 클래스를 먼저 만듭니다. 아직 초보라 그런지 프로그램(혹은 클래스) 구조를 밑그림 그려서 하나하나 만들기는 능력밖이더군요. 그까이꺼 대충~ 머리속 혹은 이면지에 그리고는 하나씩 구현(그것도 대~충)합니다. 전체적으로 슬슬 뼈대가 갖춰지면 그 때부터

위에 예시로 들어준 Block와 Box가 어떤 역할을 하는 개체인지 알아야 답변이 가능할 것 같네요. 반드시 하나의 클래스가 독립적으로 동작할 필요는 없습니다. 의존적인 몇개의 클래스가 하나의 개체가 될 수도 있는 것이죠. 그리고 static을 사용하는 것이 꼭 나쁜 것은 아닙니다. 무작정 편하게 짜려고 사용하는 것은 문제가 있지만 동일 개체의 일괄적인 변화를 요구하는 경우라면 사용해주는 것이 맞습니다. 시작하기 전에 각각의 예상되는 개체를 정리하고,

전 담배를 하나 피우지여..아니 두개..세게...이런 -_-;

손가락 운동 부터~

흠... 저로선 클래스를 많이 안다뤄 봐서 모르겠지만서도 ㅡ.ㅡ;; 제가 하는 방법은... 우선적으로 뼈대부터 잡습니다.. 크게 크게 함수부터 만들면서 필요한 변수들을 생성하면서 살을 붙이죠... 뼈대 잡으면서 재사용 해야되겠다 싶은 부분은 주석을 달구요.. 전 응용프로그램을 오래다뤄서 객체 하나하나 명령어 주는게 좀 어색했는데
지금은 머 플래쉬에서도 마찬가지로 제 방식대로 제작하고있습니다.. 우선 크게크게 잡아서 이것 저것 잡아놓고 나서 필요한 부분

재사용이 가능한 형태.. 정말 어려운 것 같아요.. ㅠㅠ 아.. 그렇군요. 저도 최대한 소스작성할때 이것만은 지켜요. 생성자 이하 메소스들을 제작할때 최대한 config,debug관련부분을 변수로 두고 코딩앞쪽에 두고..
나중에 게임같은경우는 벨런스를 조정할때 변수이름과 주석을 보고 수정하니까 편하더라구요.
예전에는 메서드들에도 숫자가 난무해서.. 수정할라면 맨날 찾느라 죽는줄알았어요.. ㅋㅋ
수다님말씀대로 무엇보다도 재사용이 가능한 형태로 제작하라!

일단 전 언제나.
config관련 부분과 debug관련부분을 코딩 앞쪽에 둡니다. 그래야 나중에 추가수정참조할때 쉬우니까요.
그뒤에 함수들을 나열한후.. 로직은 나중에 적는쪽으로다가...(제 습관입니다.)
그리고 클래스 구조야머.. 그때그때 상황에 따라서...
다만 가급적.. 다음에 재사용 가능한 형태로 클래스를 만드는 편입니다.
그래야 재산이 쌓이겠지용.