Java: Applicazione di oggetti doppiamente collegati

Question

Sto progettando un motore di gioco in Java.

Al centro di questo motore esistono le due classi Asset e Attribute, in cui un asset ha un elenco di attributi. La maggior parte degli Attributi non ha bisogno di link per tornare al loro Attributo, il che significa che gli Attributi possono e spesso appaiono negli elenchi di più di un Bene. Tuttavia, esiste un'estensione dell'Attributo chiamata UniqueAttribute, che è un'implementazione per quelli che sono specifici del loro Asset e utilizza un link back.

1. Idealmente, il metodo AddAttribute di mio Asset sarebbe simile a questo se ho tagliato fuori l'altro codice:

   public void addAttribute(Attribute attribute){ 
       if(attribute instanceof UniqueAttribute) 
       ((UniqueAttribute)attribute).setAsset(this); 
       attributeList.add(attribute); 
   } 
   

   Purtroppo, poiché vivono in diversi pacchetti, UniqueAttribute.setAsset() deve essere pubblico . Questo lascia il metodo aperto agli utenti esterni del motore con cui pasticciare, e anche se potrei semplicemente farlo a mano dicendo che usare direttamente questo metodo è un bug - sembra piuttosto sciatto.

2. La seconda opzione è quella di fornire al UniqueAttribute con l'attività per la costruzione, il che significa che il codice al momento della creazione sarebbe simile a questa:

   asset.addAttribute(new UniqueAttribute(asset)); 
   

   Anche se posso aggiungere un check-e- gettabile o asserito per confermare che la risorsa corretta è passata, fondamentalmente sto facendo affidamento sull'utente per connettere i due, che anch'io preferirei non fare.

3. La terza opzione consiste nel mordere il proiettile e inserire tutti e 50 i file java nello stesso pacchetto in modo da poter utilizzare solo la visiblity standard.

C'è una sorta di modello o qualcosa che vi aiuterà collegare questi due insieme senza esporre i fili, o costringendomi a mettere tutto in un unico pacchetto di massa?

Rant irrilevante: non mi è mai piaciuto che il concetto di sottofacili in java non sia stato realmente ampliato in alcun modo significativo. Un sotto pacchetto, per quanto riguarda java, è semplicemente un pacchetto diverso, e ci sono state molte occasioni in cui ho potuto fare con più modificatori di visibilità direttamente correlati a questo.

Answer 1

Il mio suggerimento sarebbe che Asset, Attribute e UniqueAttribute dovrebbero essere tutti nello stesso pacchetto (possibilmente insieme ad alcune altre classi "motore" di base). Quindi puoi utilizzare la visibilità del pacchetto standard per UniqueAttribute.setAsset.

Non è necessario inserire tutte le altre classi nello stesso pacchetto: il metodo Asset.addAttribute deve essere pubblico e accessibile da altri pacchetti, in modo che il resto dell'applicazione possa utilizzarlo direttamente.

Quindi la soluzione potrebbe essere denominata "3-" nella categorizzazione.

Come alcuni punti più generali, in considerazione anche:

• Sia che si ha realmente bisogno la complessità di entrambi gli attributi e UniqueAttributes - non sono sicuro che davvero, dopo aver implementato un modello di oggetti di gioco abbastanza complesso senza bisogno di qualcosa che assomiglia a un UniqueAttribute. Se UniqueAttribute "ha bisogno di un link" allora forse sta cercando di essere troppo intelligente/fare troppo?
• Anche se ne hai bisogno entrambi, vuoi davvero scrivere codice che li tratti allo stesso modo/come parte della stessa gerarchia di oggetti? sembrano abbastanza concettualmente diversi e finirai per scrivere un sacco di codice condizionale se confilerai i due .....
• Ci sono vari altri vantaggi degli attributi che sono costantemente condivisi e immutabili - è meglio per l'utilizzo della memoria, la concorrenza e testabilità tra le altre cose. E poiché sono presumibilmente piuttosto piccoli, il costo della semantica copy-on-write è banale nei casi in cui ne hai bisogno.

Answer 2

Beh, in fondo si vuole fare 3 cose: metodo setAsset

1. rendere visibile all'interno della confezione contenente classe Asset
2. metodo nascondere setAsset da tutti gli altri pacchetti
3. non utilizzano sottopacchetti per raggiungere quello

Questo è un po 'problematico: se si dichiara pubblico quel metodo nella classe Attributo tutte le altre classi compreso th al pacchetto (chiamiamolo AttributePackage), non è possibile impedire a l'utente di includere da qualche parte quel pacchetto.

D'altra parte si potrebbe effettuare le seguenti operazioni:

1. creare un'interfaccia che contiene solo il metodo attributo che l'utente deve utilizzare, chiamiamolo AttributeInterface
2. make Attributo implementare tale interfaccia
3. aggiungere AttributeInterface a un nuovo pacchetto

Un utente che desidera utilizzare la classe di attributi deve utilizzarlo tramite AttributeInterface nel frattempo Asset utilizzerà direttamente la classe Attribute per accedere a tutti i metodi.

Farò un esempio:

//attribute interface package 
public interface AttributeInterface{ 
    public void publicAttributeMethodClientShouldUse(); 
} 

//attribute package 
public class Attribute{ 
    public void setAsset(Asset a); 
    public void publicAttributeMethodClientShouldUse(); 
} 

Asset farà riferimento direttamente Attributo intanto utente deve fare riferimento AttributeInterface. Spero di essere chiaro.

Answer 3

vorrei aggiungere un metodo di callback in attributo che viene chiamato quando viene aggiunto a un bene un'istanza di attributo:

class Attribute { 
    protected void addedToAsset(Asset asset) { 
     // do nothing 
    } 
} 

Questo metodo sarebbe chiamato nel metodo AddAttribute

class Asset { 
    public void addAttribute(Attribute attribute) { 
     attributeList.add(attribute); 
     attribute.addedToAsset(this); 
    } 

} 

E il metodo sarebbe sovrascritto in UniqueAttribute per controllare il collegamento con Asset:

class UniqueAttribute extends Attribute { 
    Asset asset; 
    protected void addedToAsset(Asset asset) { 
     // manage the previous link if needed 
     if (this.asset != null) { ... } 
     this.asset = asset; 
    } 
} 

Con questa soluzione, Asset e Attributo dovrebbero essere messi nello stesso pacchetto. Ma UniqueAttribute potrebbe essere in qualsiasi pacchetto tu voglia.

Answer 4

Modificare la vostra opzione scond

asset.addAttribute(new UniqueAttribute(asset)); 

come questo:

class UniqueAttribute { 
Asset asset; 
    public UniqueAttribute(Asset asset) { this.asset = asset; asset.addAttribute(this); } 
} 

fare un approccio simile per l'attributo non univoco. Ciò significa che invece di usare addAttribute() dall'esterno, usarlo solo all'interno dei costruttori.

Un'altra opzione consiste nell'aggiungere due metodi di fabbrica a Asset: createAttribute() e createUniqueAttribute();

Answer 5

In primo luogo, queste entità do sembrano così strettamente correlate da essere inserite nello stesso pacchetto. Li metterei nello stesso pacchetto e rendere privato il pacchetto metodo addAttribute.

Tenete a mente che, dall'introduzione di AccessibleObject in Java, la visibilità e il controllo degli accessi nella lingua sono diventati solo cosmetici ... Chiunque usi la vostra libreria può prendere lezioni e rendere i metodi e i campi privati ​​accessibili e modificabili! Diavolo, possono anche modificare i membri di final! Quindi, non mettere molta enfasi sull'aspetto di visibilità e solo assicurarsi che il flusso del modello e del metodo abbia senso per gli utenti e funzioni correttamente.