'''Category:''' JavaSpaceIdioms
----
'''Intent:''' Use an Entry as a Tuple that describes an embedded object rather than trying to treat an Entry as a first-class, fully encapsulated object.

'''Motivation:''' Creates a SeparationOfConcerns between objects and tuples that describe objects.  Addresses the DirectFieldAssignment problem by recognizing the true nature of Entries as an ordered-collection of fields.

'''Solution:''' Use an Entry as a Tuple that describes an embedded object rather than trying to treat an Entry as a first-class, fully encapsulated object. For example:


 public class M''''''etaObjectEntry implements Entry
 {
     public Object object;
     .
     .
     .
     public M''''''etaObjectEntry( Object object )
     {
         this.object = object;
     }
 }

The idea is to, instead of having your objects extend Entry, you model them as you normally do. You then extend M''''''etaObjectEntry and add public fields for the matching criteria you want to expose from the embedded object. This creates a SeparationOfConcerns between objects and tuples that describe objects. For example:

 public class M''''''etaPerson extends M''''''etaObjectEntry
 {
     public String fname;
     public String lname;
 }

You could even create a convenience constructor that copies the data from the Person object:


 ...

     public M''''''etaPerson( Person person )
     {
         super( person );
         .
         .
         .
         fname = person.getNameFirst();
         lname = person.getNameLast();
     }
 }

You can then use the Tuple as a Meta''''''Person like so to look up a person object with a specified last name:

 M''''''etaObjectEntry pattern = new M''''''etaPerson();
 pattern.lname = "D''''''iFalco";
 .
 .
 .
 M''''''etaObjectEntry metaEntry = space.read( pattern );
 Person person = (Person)metaEntry.object;

This method gives up on trying to make an Entry act like a fully-encapsulated object by not fighting its true nature as an ordered-collection of fields.

-- RobertDiFalco
----
I HaveThisPattern. I ended up with a solution like this as a result of wanting unit tests I could run without having JavaSpaces running and to minimize cross-package dependencies.  The package that uses the "regular" first-class objects does not depend on JavaSpaces. It manipulates the objects and when needed uses a store which is defined as a interface. One of the implementations of the store uses JavaSpaces and wraps the objects in an Entry meta-object as described in this pattern.  Only the store implementation package depends on JavaSpaces. There is a different, simple-minded, implementation of the store that can be used as a mock in unit tests. An interesting side note: unit testing and refactoring led to EntryAsMetaObject emerging in my code. --StevenNewton
----
See also EntryWrapping