2010-08-21 12 views
5

Estoy trabajando en un juego básico de iPhone que requiere un mapa de mosaico de una sola pantalla. Nada difícil allí. Vengo de un fondo C, por lo que mi solución actual se ve un poco como esto:matrices bidimensionales en Objective-C?

typedef struct _Tile { 
    NSString *type; 
} Tile; 

@interface Map { 
    Tile mapData[MAP_TILE_MAX_X][MAP_TILE_MAX_Y]; 
} 

Esto funciona bien, pero me pregunto si hay una manera un poco más 'correcta' para manejar las cosas a través de Objective-C. Así es como veo la situación si adoptara un enfoque de Objective-C: crearía una clase de mosaico base para mantener las propiedades de teselas básicas, que luego podría subclase para tipos de mosaicos específicos (@interface Water : Tile {}, por ejemplo). Esto me permitiría tener también una lógica específica para Tile. Por ejemplo: la clase Tile podría tener un método 'pensar' que ejecutaría cualquier lógica necesaria. En mi subclase Agua, esto puede implicar la creación de un efecto dominó si el jugador se sumergió.

Mis preguntas a continuación:

  1. ¿Es aceptable el uso de estructuras C en esta situación? Si no, ¿estoy en el camino correcto con respecto a mi enfoque Obj-C?
  2. Si tuviera que crear una clase base Tile y usar subclases para tipos de mosaico específicos, ¿cómo crearía una instancia dinámica de cada subclase de mosaico (dado que tengo un NSString que contiene el tipo 'agua', necesitaría crear una instancia de la clase Water)

Respuesta

1

La segunda parte de su pregunta es más fácil de tratar, por lo que se acercará a la primera.

dinámicamente instancias de un objeto de una clase arbitraria en tiempo de ejecución se puede hacer usando NSClassFromString()

Asumiendo que su WaterTile es una subclase de UIView (que parece tener sentido, ya que es probable que para ser dibujado en la pantalla)

UIView *newTile = [[NSClassFromString([NSString stringWithFormat:@"%@TileView", [@"water" capitalizedString]]) alloc] init]; 

Ahora para la primera parte.

Dado que el mosaico es algo que desea dibujar en la pantalla, se beneficiará de todas las bondades de OO al heredar de UIView, que responderá a los eventos táctiles y tendrá los métodos necesarios para posicionar y dibujar. Esta es la principal ventaja sobre el uso de una estructura para tus fichas.

Lo más probable es que la clase de mosaico abstracta que está pensando en realidad no será necesaria ya que la mayoría de las propiedades y métodos proporcionados por UIView me llevan a pensar que quizás desee definir un Tile @protocol.

@protocol TileViewDrawing 
- (void)drawThinking; 
@end 

@interface WaterTileView : UIView <TileViewDrawing> 
@end 

@implementation WaterTileView 
-(void)drawThinking 
{ 
    // Code to show rippling effect 
} 
@end 

para crear un matrices 2D en sus Map definir un NSArray (columnas) de NSArrays (fila)

-1

Usar estructuras es lo que yo haría aquí .., me encanta usarlas, ya que hace que mi código se vea increíble y fácil de usar.

Apple también lo usa, ¿qué pasa con NSRect NSPoint y NSSize?

También me almacenar tipos como:

typedef enum{ 
    TileTypeDefault = 0, 
    TileTypeSomething, 
    TileTypeLOL 
} TileType; 

interruptor ((TileType) tipo) { caso TileTypeDefault: [[TileDefault alloc] initWithSize: tamaño]; break; }

y así sucesivamente .. si usted realmente no consigue lo que iam tratando de decir mi comentario: P

+0

Soy consciente de las enumeraciones. Pero, ¿puedes justificar el uso de una estructura aquí en lugar de una clase? No estoy particularmente interesado en hacer que mi código sea "increíble", solo me gustaría hacerlo correcto. – ndg

Cuestiones relacionadas