“Property Container” design-pattern in-depth definition

Question

Could anybody, please, explain what is a Property Container or at least where can I get information about that pattern on the Internet?

I've found that it exists as one of the Fundamental patterns in this article. Unfortunately, it is not described in the corresponding English article. The only thing is a short description in Wikipedia that I've tried to approximately translate below:

This pattern allows to add additional properties for the class in container (inside the class), instead of extending the class with the new properties.

If a short example is possible in PHP / C# / C++ or Java, it would be quite useful for understanding.

P.S.: It seems like it has been described in "SanFrancisco(TM) Design Patterns: Blueprints for Business Software", but I don't have access to it. Google does not help or I'm searching with the wrong keywords...

Answer 1

A Property Container is a class whose properties can be customized at runtime without having to edit your class definition.

This article has the only thorough example I could find. In it, they use the example of a customizable Movie class.

The PropertyContainer base class provides methods to add/remove/retrieve properties stored in the class. Basically, it acts a lot like a HashMap:

PropertyContainer:
   + addPropertyBy()
   + removeProperty()
   + getPropertyBy()
   + getPropertyKeys()

Then you have a Movie class that inherits from the PropertyContainer:

Movie extends PropertyContainer:
   - rating
   - available
   - description
   - title
   - id
   - price

   + [getters and setters for private properties]

Later, if you need to add releasedate as a property to the Movie class in one project, you have the ability to add it at runtime instead of updating your class.

Movie m = new Movie()
m.addPropertyBy("3/5/14", "releasedate")

Answer 2

In my experience, I have seen this applied as generic storage on an object.

An object either has a relationship to other "property" objects which are stored in a hashtable or list, or an object simply has an internal hashtable associating keys to values.

This allows data to be added at runtime that was not considered at design time. This can be really good or really bad.

Good: an object is designed to be extensible, maybe containing arbitrary data defined by customers or users. If that is its purpose in life, this can be powerful.

Bad: an object may take on concerns that it should not. The extra storage may encourage the use of various anti-patterns related to object state and responsibilities.

Java example:

import java.util.*;

public class Example {
  private Map<String, Object> properties = new HashMap<>();

  public void setProperty(String key, Object value) {
    properties.put(key, value);
  }

  public Object getProperty(String key) {
    return properties.get(key);
  }

  // Might also want to expose other methods such as containsKey() or clear().
}

Answer 3

The simplest explanation is "A Service locator for properties" or more shorter "Data locator".

And it's also an antipattern from OOP point of view as it breaks its main concept - Encapsulation and reduces type safety, when the modern development trend is exactly the opposite: from weak typing to strong (e.g. JavaScript -> TypeScript).

In terms of Functional programming it's even worse as mutable construction in essence.

But for Procedural programming it's the way to go implementing extensible platform.

Answer 4

I've written my PHP implementation for “Property Container” design-pattern. (https://codereview.stackexchange.com/q/43485/36845)

Be sure to check recommendations that were suggested in the "answer" post as well.