Come capire se una proprietà è un membro di una classe o devo creare una classe diversa che la detiene?

In generale, quando si esegue la programmazione orientata agli oggetti, si desidera che i dati e il comportamento siano insieme (in una classe).

Vuoi anche raggiungere un'elevata coesione con le tue classi. Ciò significa che la maggior parte / tutti i tuoi metodi usano la maggior parte / tutti gli attributi della tua classe. Questo ti aiuterà a raggiungere il principio della responsabilità unica. Bassa coesione significa che parte dei dati non viene utilizzata quando vengono intraprese determinate azioni (il che significa che non è correlato all'azione, il che significa che probabilmente non dovrebbe essere nella stessa classe). Seguendo questi principi creeremo molte classi piccole ma focalizzate.

In generale, dovresti sempre essere in grado di indicare ciò che la tua classe fa in una singola frase senza usare la parola "e". Se non puoi farlo, probabilmente la tua classe sta facendo troppo.

Le classi sono spesso utilizzate per concetti, per tenere insieme tutti gli attributi del concetto e le interazioni possibili.

Nel decidere cosa fare, tuttavia, è puramente una questione di ciò che funziona meglio e quale è il design migliore. Quando decidi cosa fare, lo farei in questo modo: se il calcolo fa parte dell'oggetto (essere), crea una classe per esso. Se no, non farlo. Ovviamente ci saranno decisioni non chiare ( player.paint() o paint(player) ), ma funziona come linea guida generale. Prendi anche in considerazione il disordine che puoi creare mantenendo le cose non organizzate.

Ad esempio: diciamo che abbiamo una macchina. Questa macchina ha ruote, un guidatore, passeggeri e carico. Quello che vogliamo fare è associare le ruote, il guidatore, i passeggeri e il carico con la macchina, quindi trasformiamo la macchina in una classe con tutte quelle cose, forse solo i puntatori agli oggetti reali.

Ora diciamo che abbiamo un mondo di cui ce n'è solo uno nell'intero programma. Le distanze saranno misurate senza riferimento a una classe o oggetto World . Questo perché il mondo, almeno in questo caso, non è in realtà una raccolta di attributi. Anche se avesse una dimensione massima, non lo definiremmo necessariamente come classe, perché non è molto utile, ci sarebbe più confusione a causa di ciò, e non è davvero utile per niente.

Ci sono naturalmente anche esempi in cui è difficile decidere. Se abbiamo molti alberi potremmo memorizzare tuple di coordinate xey in una collezione chiamata trees . Tuttavia, potremmo anche creare una classe Tree e archiviare le nostre informazioni lì. Se lo si debba fare o meno si riduce a quanto segue:

• Darai loro metodi extra come paint , update , grow e così via?

• Saranno oggetti con molti attributi extra che vuoi tenere insieme? Ti piace dimensione, età, forma e così via?

Should, for example, each tile store the data of its reward or there should be a reward manager for checking how many tiles are consecutive next to each other to give the reward to the player?

Come lo farei

Hai un oggetto Reel che può essere spun randomizzato

Hai un numero di oggetti Reward che hanno una soglia richiesta per vincere e una quantità di premi da distribuire (puoi rendere la soglia e gli oggetti premio in se stessi)

Gli oggetti Reward si registrano con gli oggetti Reel per ascoltare i risultati degli spin (pub / sub standard)

Quando Player filtra ogni Reel messaggi oggetto il risultato del suo lancio sull'oggetto Premio, che inizia a controllare le soglie.

Un premio tiene traccia del risultato mentre i rulli riportano e se viene abbinata una soglia (es. 3 tessere ciliegia, ma non più), i messaggi ricompensa l'oggetto Giocatore per aumentare il valore del saldo del giocatore per l'importo del premio.

Non c'è bisogno di un gestore di premi, ogni ricompensa è un oggetto stesso. I manager sono generalmente un segno in cui i tuoi oggetti non si parlano correttamente. In questo caso la bobina dovrebbe parlare direttamente al premio.