Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / programming / performance

Vacuole Encapsulation

4.43/5 (3 votes)
24 Mar 2014CPOL2 min read 7.8K  
Encapsulation approach to bring data sources and implementations closer together, allowing reflection-like behavior in a format that mere mortals can read.

Before you Google “Vacuole Encapsulation,” let me introduce you to my totally-made-up programming idea called a Vacuole.

I was working on a problem where a single user had potentially 200 identical address objects (4 per US State). This overwhelming data load ultimately brought me to a solution where beans use maps for portable data storage, allowing the sharing of identical address values, condensing those 200 addresses down to as little as 4.

While I felt augmenting data storage with maps was a niche solution to a specific problem, it led me to some surprisingly comfortable synergies later on in validation and mapping. I developed a handful of simple utilities that were applicable to any value bean implementing Vacuole.

Vacuole Encapsulation

Vacuole Encapsulation is a slightly different approach from encapsulation. You still get standard issue encapsulation accessors and mutators. But, instead of variables, a Map is used for data storage with Vacuoles as the Object key. The most important aspect of this pattern, the Vacuole, contains everything and anything that the Bean and its contents need to be effective and thrive, such as:

  • Unique Identifier ( Random UUID? )
  • Classification ( Column name? useful for comparing like values)
  • Contract ( Validation Adaptors )
  • Data Type ( Eg: Class )
  • Field Length ( < input maxlength = ” ? ” … /> )
  • Required Input? ( * )
  • Or anything else you deem necessary

This behavior of using Maps with a Vacuole key can process data with very little code, making routine tasks like validation, mapping, and comparison, a refreshingly easy task with very shallow trace calls and zero reflection.

Case Example

You need to populate request data from a form. Where the Vacuole’s unique identifiers are applied to input name attributes of form elements, re-uniting each form variable input with the exact bean is easy. Here is an example of Validate/BeanMapping from a Request object:

C#
public class VacuoleUtils {
    public static List<ValidationResult> handleRequest(HttpServletRequest req, 
                  List<VacuoleBean> vBeans) {
        List<ValidationResult> results = new ArrayList<>();
        for (VacuoleBean vBean : vBeans) {
            for (Vacuole v : vacuoleBean.getVacuoles()) {
                for (Validator val : v.getValidations()) {
                    Object value = req.getParameter(v.getId());
                    ValidationResult result = val.check(value);
                    if (result.pass()) vBean.setValue(v,req.getParameter(v.getId()));
                    else results.add(result);
                }
            }
        }
        return results;
    }
}

Vacuoles are still a curiosity for me, and I look forward to exploring and discovering the utility this little idea has in store.

At some point, with a blessing from Keyhole, I hope to make available some source code through Github! Until then, I recommend you take these concepts and apply them independently. Good luck!

– Ryan McCullough

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)