Vacuole Encapsulation

Ryan McCullough Programming 4 Comments

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 to 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:

public class VacuoleUtils {
    public static List handleRequest(HttpServletRequest req, List vBeans) {
        List 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.

See Also:  Elm Language

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, [email protected]

Comments 4

    1. That’s great to hear. Would you care to share a bit more about your implementation? Were you just using maps for data transport, or using complex keys?

      1. Complex Keys! – we used them for validation, automatic db-statement generation, tree-like inheritance of settings where one could define setting-values on different levels of a tree-hierarchy etc.

What Do You Think?