Un modo carino per fare riferimento a due oggetti immutabili?

Question

Prendete questi due classi Java:

class User { 
    final Inventory inventory; 
    User (Inventory inv) { 
     inventory = inv; 
    } 
} 

class Inventory { 
    final User owner; 
    Inventory (User own) { 
     owner = own; 
    } 
} 

Esiste un modo without using reflection* per tirare fuori questo? In realtà non mi aspetto che lo sia, ma non può far male a chiedere.

Aggiornamento: Poiché nella costruzione bytecode ha due fasi (1. destinare oggetto, 2. chiamata del costruttore **) questo potrebbe essere (ab) usato per fare questo, con bytecode scritto a mano o un compilatore personalizzato? Sto parlando di eseguire prima il passaggio 1 per entrambi gli oggetti, poi il passaggio 2 per entrambi, usando i riferimenti del passaggio 1. Ovviamente qualcosa del genere sarebbe piuttosto ingombrante, e questa parte della domanda è accademica.

(* Perché riflessione può dare problemi con un responsabile della sicurezza)

(** dice la mia limitata conoscenza)

Answer 1

Questo può funzionare solo in modo pulito se uno degli oggetti è stato creato da altri. Ad esempio è possibile cambiare la classe User a qualcosa di simile (pur mantenendo la classe Inventory invariato):

class User { 
    private final Inventory inventory; 
    User() { 
     inventory = new Inventory(this); 
    } 
} 

È necessario essere attenti su come accedere all'oggetto User nel costruttore Inventory, però: non è completamente inizializzato ancora . Ad esempio, il suo campo inventory sarà ancora null!

Aggiornamento annuncio: ora ho verificato che l'approccio bytecode-manipolazione non non funziona. L'ho provato usando Jasmin e non è mai riuscito a caricare con un VerifyError.

Scavando più a fondo nel problema, ho trovato § 4.10.2.4 Instance Initialization Methods and Newly Created Objects. Questa sezione spiega come la JVM garantisce che solo le istanze di oggetti inizializzate vengano passate in giro.

Answer 2

È possibile farlo se non è necessario iniettare uno degli oggetti.

class User { 
    private final Inventory inventory; 
    User() { 
     inventory = new Inventory(this); 
    } 
} 

Answer 3

class User { 
    private final Inventory inventory; 
    User (/*whatever additional args are needed to construct the inventory*/) { 
     //populate user fields 
     inventory = new Inventory(this); 
    } 
} 

class Inventory { 
    private final User owner; 
    Inventory (User own) { 
     owner = own; 
    } 
} 

Questo è il meglio che posso pensare. Forse c'è un modello migliore.

Answer 4

Questa è una "soluzione", anche se la perdita di uno final è scomoda.

class User { 
    Inventory inventory; 
    User() { } 
    // make sure this setter is only callable from where it should be, 
    // and is called only once at construction time 
    setInventory(inv) { 
     if (inventory != null) throw new IllegalStateException(); 
     inventory = inv; 
    } 
} 

class Inventory { 
    final User owner; 
    Inventory (User own) { 
     owner = own; 
    } 
} 

Answer 5

Se siete interessati solo a JVM bytecode e non si cura di codifica in Java specificamente, magari utilizzando Scala o Clojure potrebbe aiutare. Avrai bisogno di una sorta di macchinario letrec.

Answer 6

Leggermente pedante, ma non è strettamente necessario crearne uno dentro l'altro, se non vi dispiace un po 'di indecisione. Potrebbero entrambi essere classi interne.

public class BadlyNamedClass { 
    private final User owner; 
    private final Inventory inventory; 

    public BadlyNamedClass() { 
     this.owner = new User() { 
      ... has access to BadlyNamedClass.this.inventory; 
     }; 
     this.inventory = new Inventory() { 
      ... has access to BadlyNamedClass.this.owner; 
     }; 
    } 
    ... 
} 

O anche:

public class BadlyNamedClass { 
    private final User owner; 
    private final Inventory inventory; 

    public BadlyNamedClass() { 
     this.owner = new User(this); 
     this.inventory = new Inventory(this); 
    } 
    public User getOwner() { return owner; } 
    public Inventory getInventory() { return inventory; } 
    ... 
} 

Answer 7

B: "Inventario creati dall'utente è la nostra ultima speranza".
Y: "No, ce n'è un altro."

Se si astraggono i riferimenti a una terza parte, è possibile controllarne la relazione.

Ad esempio.

public class User 
{ 
    private final String identifier; // uniquely identifies this User instance. 

    public User(final String myIdentifier) 
    { 
     identifier = myIdentifier; 

     InventoryReferencer.registerBlammoUser(identifier); // Register the user with the Inventory referencer. 
    } 

    public Inventory getInventory() 
    { 
     return InventoryReferencer.getInventoryForUser(identifier); 
    } 
} 

public interface Inventory // Bam! 
{ 
    ... nothing special. 
} 

// Assuming that the Inventory only makes sence in the context of a User (i.e. User must own Inventory). 
public class InventoryReferencer 
{ 
    private static final Map<String, Inventory> referenceMap = new HashMap<String, Inventory>(); 

    private InventoryReferencer() 
    { 
     throw ... some exception - helps limit instantiation. 
    } 

    public static void registerBlammoUser(final String identifier) 
    { 
     InventoryBlammo blammo = new InventoryBlammo(); 
     referenceMap.add(indentifier, blammo); 
    } 

    public static void registerKapowUser(final String identifier) 
    { 
     InventoryBlammo kapow = new InventoryKapow(); 
     referenceMap.add(indentifier, kapow); 
    } 

    public static Inentory getInfentoryForUser(final String identifier) 
    { 
     return referenceMap.get(identifier); 
    } 
} 

// Maybe package access constructors. 
public class InventoryBlammo implements Inventory 
{ 
    // a Blammo style inventory. 
} 

public class InventoryKapow implements Inventory 
{ 
    // a Kapow style inventory. 
}