2012-12-07 2 views
0

CCScene과 여러 CCSprites가 노드로 추가되었습니다. 그런 다음 하위 클래스 (동일한 CCScene 클래스 인스턴스에 추가됨)가 있습니다.이 클래스는 CCSprite에 대해 영리한 행동을합니다. 나는이 클래스가 메인 장면에 추가 된 CCSprite 노드를 참조하고 그 속성 (예 : 가시성)을 수정하도록 허용하고자한다. 내 현재 솔루션은 어떤 클래스의 멤버 변수로 NSMutableArray에 대한 포인터를 추가하는 것입니다.Cocos2d :이 디자인 패턴이 유효합니까?

CCScene 클래스를 사용하여 Whatever 클래스를 통해 이러한 동작을 트리거합니다. 예를 들어 특정 시점에 Whatever 노드에서 "TriggerAction"메서드를 호출합니다. 이 동작은 동일한 부모 CCScene에 속한 CCSprites를 수정합니다.

나는 초보자이지만 잠재적으로 위험한 것으로 들리지만, 이것이 알려진 디자인 패턴인지 아니면 더 나쁜지, 알려진 오류인지 궁금합니다.

이와 같은 패턴을 사용한 경험이 있습니까? Cocos2D는 Flash의 개념을 일부 상속하므로 태그로 "Flash"를 추가했습니다.

편집 :

특별한 스프라이트 만졌을 때 LevelIcon 스프라이트를 표시하도록되어 있음 (예를 들어 행성이) 무엇이든간에

. 내 문제는 화면의 행성 위치와 관련하여 levelIcon을 배치하고 행성을 포함하는 장면에 추가하는 것이 가장 쉬운 방법이라는 것입니다. 나는 지금 그들이 행성에만 추가 된 솔루션을 모색 할 것입니다. 어떤 하위 클래스 든 문제가됩니다. 문제는 이런 방식으로 많이 결합하고 LevelIcon을 필요로하지 않는 다른 장면에서 Whatever 클래스를 재활용 할 수 없습니다.

Is this pattern valid

+0

우리가 구체적으로 무엇을 시도했는지 이해하면 더 잘 도와 드릴 수 있습니다. "실제 게임"예제를 줄 수 있습니까? 당신이하고있는 일을 할 때 볼 수있는 실제 문제는 이러한 작업들이 어떤 순서로 진행될 지 확신 할 수 없다는 것입니다. 따라서 "무엇이든지간에"액션의 다음 반복 업데이트가 발생할 때까지는 "영향을 미치지 않을"수 있습니다. –

답변

1

그것은 확인 패턴입니다하지만 형제가 다른 형제를 유지하기 때문에 메모리가 누수의 가능성이있다.

더 나은 해결책은 제어 노드의 스프라이트 자식을 만드는 것입니다. 그렇게하면 유지 사이클의 위험을 감수하지 않아도되며, 스프라이트에 대한 참조를 유지하기 위해 별도의 배열을 가질 필요가 없습니다. 이미 자식 배열에 있으므로. 태그를 사용하여 개별 스프라이트를 식별 할 수 있습니다.

"뭐든지"실제로 아무것도 표시 할 필요가없는 경우 CCNode를 CCSprite 대신 수퍼 클래스로 사용해야합니다.

+0

터치했을 때 LevelIcon 스프라이트가 표시되는 특수 스프라이트 (예 : 행성)가 무엇이든간에. 내 문제는 화면의 행성 위치와 관련하여 levelIcon을 배치하고 행성을 포함하는 장면에 추가하는 것이 가장 쉬운 방법이라는 것입니다. 나는 지금 그들이 행성에만 추가 된 솔루션을 모색 할 것입니다. 어떤 하위 클래스 든 문제가됩니다. 문제는 이런 방식으로 많이 결합하고 LevelIcon을 필요로하지 않는 다른 장면에서 Whatever 클래스를 재활용 할 수 없습니다. – mm24

관련 문제