Separation of concerns consists of separating one kind of code from another into different sets of code so that when one concern is being worked on, it has less of an effect on the other sets of code.
Examples of Separation of Concerns
Here are four separations of concern, three are well known, the fourth is proposed:
- [Presentation/UI] and [Business logic/Model]
- [Business logic/Model] and [data storage/RDB]
- [Aspect orientation] and [Functionality]
- [Information] and [Data]
When applying separation of concerns to information concerns vs data concerns, how do you implement this? How do you implement separations of concerns regarding the information vs data distinction? What is your definition of information (vs data)?
Definition of Information vs Data
First of all, data and information are different in that information is data that has meaning. Data is data with little meaning. One way to spot the difference in real life is that usually, data comes in large quantities, whereas information is likely to be in much smaller quantities.
Information Oriented vs Data Oriented Programming
Within the realm of programming, data oriented programming works with data within a fixed context, and information oriented programming processes the context itself. Fixed data oriented programming contexts can be things such as structs, classes, xml schemas, tables, and primitive variables and methods in a program. Each of these provides a fixed context for they data they contain. With information oriented programming, the context becomes variable. Members and portions of other fixed context listed above become variably defined fields using techniques to define the meaning of each field. An example of this is when a list of fields are each defined by an an endeme. Another example happens with knowledge representation through ontologies in which the meaning of each field is defined by relating it in various ways to other fields.
Implementing the Data vs Information Separation of Concerns
To implement the separation of concerns, the code used to define the field meanings and the code used to implement the meanings is moved into a separate section of the program from where the main application is kept. This is usually a separation of the middle tier in horizontally architected programs into two pieces. In a vertical architecture, each level is separated into framework and application code and the field definitions and meaning implementation are collected into the application code. I’m still in the blue sky phase for some of this stuff, so my opinion on separation of concerns may change over time. This is how I see it now.
Separation of Presentation vs Logic Concerns
Separation of data vs information concerns has a neat side effect. As I have been working with my test bed, I have also noticed that separation of concerns – data vs information enforces separation of model vs view (logic vs presentation) concerts .
The Biggest Challenge
The biggest challenge in implementing separation of concerns is being able to identify the difference between data and information and being able to identify which tasks, work, and areas of functionality belong to which layer.