Non vorrei incoraggiare il tuo approccio specifico; è è modulare e sembra totalmente funzionale, ma suggerirei un leggero cambiamento.
Ti incoraggio a invertire la relazione tra HexGrid e HexGridLayout tale che invece di HexGridLayout accedendo direttamente e modificando le proprietà coords e center , invece le prende come parametri e restituisce un nuovo insieme di valori.
Poi ci sono due scelte per ottenere i campi coords e center aggiornati:
- Puoi dare qualsiasi
HexGridLayout che desideri utilizzare a HexGrid e HexGrid chiamerà update(coords, center) e ricevere nuovi valori per coords e center che imposterà su se stesso.
- Se attualmente
HexGrid non è quella che chiama update - allora qualsiasi classe è che la chiama su HexGridLayout dovrebbe chiamare update(hexGrid.coords, hexGrid.center) e recuperare il% aggiornatocoords / center valori aggiorna la sua istanza di HexGrid stessa.
Incoraggio il numero 2 qui sopra, perché disaccoppia completamente HexGridLayout da HexGrid mentre rendi disponibili i valori aggiornati di coords e center a chiunque desideri usarli per aggiornare un HexGrid - potresti usare 1% diHexGridLayout per ottenere valori aggiornati per qualsiasi numero di HexGrid s a causa di questo accoppiamento lento, o semplicemente usarlo per registrare o persino proiettare aggiornamenti futuri ecc.
Quindi, così com'è, il tuo design è modulare, anche se non direi che è completamente sciolto - perché il HexGridLayout è completamente dipendente dalla tua implementazione di HexGrid e non può essere usato per impaginare altri tipi di HexGrid (forse una rete basata HexGrid sarebbe utile per la funzionalità client / server che il HexGridLayout attualmente non supporterà per esempio).
