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")

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().
}

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.

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.