Monday, March 26, 2012

Field and Field Descriptor pattern


Software is simply speaking applying logic on data. For applying logic, data needs to be defined consistently so that multiple people involved can work together over long time without continuous training or feedback. This also helps in consistently applying logic. A configurable system where data definition is not coded but is defined outside in a configuration file is much more flexible to change.

So, the pattern I am talking about is applicable in places where you have data having some format which is inputted through some configuration file. So, system basically have two inputs one being data while other being format of data. System uses the latter to apply logic on former. Logic may be hardcoded or again can be configurable. But, that is not focus of this pattern. This pattern only tries to focus on the two inputs specified and their representation.

Configuration must be known before data is available when system starts. Every definition in configuration is represented by FieldDescriptor. The fieldDescriptor defines the format of that field. It may contain values like name of field, expected type, file name to expect data from, location of field in data, etc. it is problem specific. It is an immutable class that should not change value on run time once created and are thus thread safe. While loading, system parses the configuration file. Each definition in that file is converted into a FieldDescriptor object. You can apply any pattern to create it. It must however not hold actual data. Descriptor object should be comparable and must use all fields into consideration while comparing equality. Higher or lower values can be problem specific. Holding value is job of another set called Field. Once fieldDescriptor's are loaded and data is available, system now goes through descriptor list and uses it to extract data from source in format specified in fieldDescriptor. It then creates its corresponding Field object. Field object primarily has two values descriptor and value. It can have any other value depending on problem. If descriptor is not available while creating field but individual description is available then they must be passed onto field and field creates them and stores them. Field must be able to provide its value as well as descriptor when asked for.

Here is the basic scenario 
Scenario in which this pattern is applied

No comments:

Post a Comment