Quanto minore di un caso è una classe appropriata per?

2

Sto provando a utilizzare la composizione in una mia classe Entity . Finora, un'entità "è" Displayable (ereditato da un ABC) e "ha" un Position (contiene una classe puntuale). So che vorrò che la mia Entity "abbia" un / qualche stato di salute, così ho iniziato a definire una classe Health da comporre in Entity . È stato comunque semplicistico e ha finito per contenere solo 2 metodi: hurt e heal che modifica il suo singolo campo: hp .

Se avessi intenzione di ereditare da Health , immagino che questo sarebbe OK, in quanto non richiederebbe alcun file standard all'interno di Entity ; erediterebbe i metodi.

Se devo scrivere con esso, quindi per me a hurt a Entity , dovrò indirizzare la chiamata di hurt / heal al loro membro Health e chiamarli proprio metodo hurt / heal . Con una classe così semplice, questo significa che praticamente ho tutti i metodi di Health duplicati in Entity .

In un caso come questo, c'è qualche punto nel definire Health ? L'alternativa più semplice sarebbe semplicemente dare un campo Entity a hp e dargli i metodi hurt e heal direttamente.

    
posta Carcigenicate 16.04.2015 - 22:29
fonte

1 risposta

3

Finché il valore di hp sottostante non è pubblico, non importa troppo in entrambi i casi. Avere Entity :: hurt () / heal () direttamente accesso ad un membro privato HP va bene, e anche farli wrapper per una chiamata Health :: hurt () / heal () va bene.

Supponendo che non sia pubblico, baserei la decisione su cosa ti aspetti che accada in futuro. La salute sarà probabilmente un semplice numero intero per sempre? O pensi che diventerà una classe non banale con metodi come getTimesHurt (), getLastHealValue () o getPoisonTicksRemaining ()? Forse non lo sai per certo, ma puoi fare un'ipotesi ben congegnata in base al tipo di gioco che stai facendo.

    
risposta data 16.04.2015 - 22:47
fonte

Leggi altre domande sui tag