Adding field to the class at runtime - design pattern

I like the question, my two cents:

Your two approaches are radically different:

• The first one is OO ans strongly typed - but not extensible
• The second one is weakly typed (string encapsulates anything)

In C++, many would use a std::map of boost::variant to achieve a mix of both.

Disgression: Note that some languages, such as C#, allows the dynamic creation of types. Which could be a nice solution for the general issue of adding members dynamically. However, "modifying/adding" types after compilation does corrupt the type system itself, and makes your "modified" types almost useless (e.g., how would you access such added properties, since you dont even know they exists ? The only reasonable way would be a systematic reflection over each object ... ending with a pure dynamic language _ you can refer to the 'dynamic' .NET keyword)

Creating a type at runtime sounds much more complicated then just creating an abstraction layer. It is very common to create an abstraction to decouple systems.

Let me show an example from my practice. Moscow exchange has the trading core called Plaza2 with trader's API. Traders write their programs to work with financial data. The problem is that this data is very huge, complex, and highly exposed to changes. It can change after a new financial product introduced or rools of clearing changed. Nature of future changes can not be predicted. Literally, it can change every day and poor programmers should edit the code and release a new version, and angry traders should revise their systems.

Obvious decision is to hide all financial hell behind an abstraction. They've used well known SQL tables abstraction. Biggest part of their core can work with any valid schema, the same as trader's software can dynamically parse the schema and find out whether it is compatible with their system.

Returning back to your example, it is normal to create an abstract language in front of some logic. It could be "property", "table", "message", or even human language, but pay attention to the drawbacks of this approach:

• More code for parsing and validating (and more time off course). Everything what compiler did for you with static typing you must do in the run-time.
• More documentation of messages, tables or other primitives. All the complexity goes from code to some sort of schema or standart. Here is an example of above-mentioned financial hell schema: http://ftp.moex.com/pub/FORTS/Plaza2/p2gate_en.pdf (dozens of pages of tables)

Is this approach a known design pattern?

In XML and HTML, these would be the attributes to a node/element. I've also heard them called extended properties, name/value pairs, and parameters.

Would you solve the problem differently?

That is how I would solve the problem, yes.

I know there are languages where I can add a field in runtime, but what about database?

A database would be like Java, in some senses. In pesudo-sql:

TABLE products
(
    product_name VARCHAR(50),
    product_id INTEGER AUTOINCREMENT
)

TABLE attributes
(
    product_id INTEGER,
    name VARCHAR(50),
    value VARCHAR(2000)
)

This would correspond to the Java

class Product {
   protected String productName;
   protected Map<String, String> properties;
}

Note that there is no need for a Property class, as the Map stores the name as the key.

Would you rather add/alter columns or used someting as shown above?

I've tried the add/alter column thing, and it was a nightmare. It can be done, but things kept getting out of sync and I never got it to work well. The table structure I outlined above has been much more successful. If you need to do searches and order by's, consider using an attributes table for each data type (date_attributes, currency_attributes, etc.) or adding some of the properties as good old database columns in the products table. Reports are often much easier to write on database columns then sub tables.

There is the State Desing Pattern a-la Gang-of-Four, which makes an object appear to change its type or class at run-time.

Other alternatives are Observer Design Pattern or a Proxy Design Pattern