Einfache Datenbank-ähnliche Erfassungsklasse in Java

Question

Das Problem: Pflegen Sie eine bidirektionale Viele-zu-Eins-Beziehung zwischen Java-Objekten.

So etwas wie die Google/Commons Sammlungen bidi Karten, aber ich möchte doppelte Werte auf der Vorderseite ermöglichen und Sätze der vorderen Tasten wie die Rückseite Werte aufweisen. Gebraucht etwas wie folgt aus:

// maintaining disjoint areas on a gameboard. Location is a space on the 
// gameboard; Regions refer to disjoint collections of Locations. 

MagicalManyToOneMap<Location, Region> forward = // the game universe 
Map<Region, <Set<Location>>> inverse = forward.getInverse(); // live, not a copy 
Location parkplace = Game.chooseSomeLocation(...); 
Region mine = forward.get(parkplace); // assume !null; should be O(log n) 
Region other = Game.getSomeOtherRegion(...); 
// moving a Location from one Region to another: 
forward.put(parkplace, other); 
// or equivalently: 
inverse.get(other).add(parkplace); // should also be O(log n) or so 
// expected consistency: 
assert ! inverse.get(mine).contains(parkplace); 
assert forward.get(parkplace) == other; 
// and this should be fast, not iterate every possible location just to filter for mine: 
for (Location l : mine) { /* do something clever */ } 

Die einfache Java-Ansätze sind: 1. Um nur eine Seite der Beziehung zu pflegen, entweder als Map<Location, Region> oder ein Map<Region, Set<Location>>, und die inverse Beziehung von Iteration zu sammeln, wenn erforderlich; Oder 2. Einen Wrapper erstellen, der die Maps beider Seiten verwaltet und alle mutierenden Aufrufe abfängt, um beide Seiten synchron zu halten.

1 ist O (n) anstelle von O (log n), was ein Problem wird. Ich begann mit 2 und war sofort im Unkraut. (Wissen Sie, wie viele verschiedene Möglichkeiten es gibt, einen Map-Eintrag zu ändern?)

Dies ist fast trivial in der SQL-Welt (Location-Tabelle erhält eine indizierte RegionID-Spalte). Gibt es etwas Offensichtliches, das ich vermisse, das es für normale Objekte trivial macht?

Answer 1

Ich denke, Sie könnten mit den folgenden zwei Klassen erreichen, was Sie brauchen. Obwohl es sich um zwei Karten handelt, sind sie nicht der Außenwelt ausgesetzt, daher sollte es für sie keine Möglichkeit geben, nicht synchron zu sein. Wenn ich die gleiche "Tatsache" zweimal speichere, glaube ich nicht, dass Sie das in irgendeiner effizienten Implementierung umgehen können, egal ob die Tatsache doppelt so gespeichert wird wie hier, oder implizit, wie wenn Ihre Datenbank einen Index erstellt um Joins effizienter an Ihren 2 Tischen zu machen. Sie können dem magicset neue Dinge hinzufügen und beide Mappings aktualisieren, oder Sie können dem magmapper Dinge hinzufügen, die dann die inverse Map automatisch aktualisieren. Die Freundin ruft mich jetzt ins Bett, also kann ich das nicht durch einen Compiler laufen lassen - es sollte genug sein, um loszulegen. Welches Rätsel versuchen Sie zu lösen?

public class MagicSet<L> { 
    private Map<L,R> forward; 
    private R r; 
    private Set<L> set; 

    public MagicSet<L>(Map forward, R r) { 
     this.forward = map; 
     this.r = r; 
     this.set = new HashSet<L>(); 
    } 

    public void add(L l) { 
     set.add(l); 
     forward.put(l,r); 
    } 

    public void remove(L l) { 
     set.remove(l); 
     forward.remove(l); 
    } 

    public int size() { 
     return set.size(); 
    } 

    public in contains(L l){ 
     return set.contains(l); 
    } 

    // caution, do not use the remove method from this iterator. if this class was going 
    // to be reused often you would want to return a wrapped iterator that handled the remove method properly. In fact, if you did that, i think you could then extend AbstractSet and MagicSet would then fully implement java.util.Set. 
    public Iterator iterator() { 
     return set.iterator(); 
    } 
} 



public class MagicMapper<L,R> { // note that it doesn't implement Map, though it could with some extra work. I don't get the impression you need that though. 
private Map<L,R> forward; 
private Map<R,MagicSet<L>> inverse; 

public MagicMapper<L,R>() { 
     forward = new HashMap<L,R>; 
     inverse = new HashMap<R,<MagicSet<L>>; 
} 


public R getForward(L key) { 
     return forward.get(key); 
} 


public Set<L> getBackward(R key) { 
     return inverse.get(key); // this assumes you want a null if 
           // you try to use a key that has no mapping. otherwise you'd return a blank MagicSet 
} 

public void put (L l, R r) { 

     R oldVal = forward.get(l); 

     // if the L had already belonged to an R, we need to undo that mapping 
     MagicSet<L> oldSet = inverse.get(oldVal); 

     if (oldSet != null) {oldSet.remove(l);} 

     // now get the set the R belongs to, and add it. 
     MagicSet<L> newSet = inverse.get(l); 

     if (newSet == null) { 
       newSet = new MagicSet<L>(forward, r); 
       inverse.put(r,newSet); 
     } 
     newSet.add(l); // magically updates the "forward" map 
} 


} 

Answer 2

Ich könnte Ihr Modell missverstehen, aber wenn Ihr Standort und Ihre Region korrekt equals() und hashCode() implementiert haben, dann ist der Satz von Ort -> Region nur eine klassische einfache Map - Implementierung (mehrere unterschiedliche Schlüssel können auf den verweisen gleicher Objektwert). Die Region -> Set of Location ist eine Multimap (verfügbar in Google Coll.). Sie könnten Ihre eigene Klasse mit den richtigen add/remove-Methoden erstellen, um beide Submaps zu bearbeiten.

Vielleicht ein Overkill, aber Sie könnten auch In-Memory-SQL-Server (HSQLDB, etc) verwenden. Es ermöglicht Ihnen, einen Index für viele Spalten zu erstellen.