<< Correct Use
Page 7: LIGHT Data and Architectures
A third important distinction in any application is that between data and architectural interfaces. This is a distinction between content and transport - where the data is the sausage and the architecture is the sausage machine, or the letter and postal service.
In the case of the postal service, the analogy can be carried further. The letters are distinct from the postal service, even thought they may carry a weak reference to their carrier (for example a postal mark). However, the postman is not attached to the letter.
Where the modules and services are coupled using light interfaces, and LIGHT data interfaces are passed around.
Architectural and Data LIGHT interfaces should be treated differently. An object that has or contains references to architectural objects (e.g. Files, Connections, Sessions) is an architectural object. An object that has no references to architectural objects is a data object. Where Data objects have LIGHT interfaces they can themselves be light objects.
The File examples shown on the previous pages are examples of architectural interfaces. The String being passed to the architectural interface is an example of a data object.
The Content/Transport example above could be amended with an example of a LIGHT data object called Content. For example:
public class Content
public String getData();
public void setData(String data);
public Date getDate();
public void setDate(Date date);
The File interface can now be extended:
public class File
public Content getContent();
public void setContent(Content content);
By making this distinction between Data and Architecture objects, we now have the principles with which to build systems that pass data between loosely coupled components at the architectural level.
|HEAVY OO Only Architecture
Where operations on the HEAVY objects are distributed throughout, and there is no distinction between data and architectural interfaces.
Why is it so important to make this distinction between architecture and data? Some Object Oriented advocates believe the distinction is unimportant. For example, objects should be able to persist themselves. The problem with this is that it creates the Object Oriented equivalent of the GOTO statement. The GOTO statement has been outlawed by programmers because it
creates spaghetti code.
When programmers give data objects architectural powers, they are effectively deferring taking an operation and displacing it. Allowing an architectural operation to be performed elsewhere in the code creates the same arbitrary spatial displacement that the GOTO statement once performed.
Imagine the Content object having a save method. The content object could be passed up and around the system, to an arbitrary destination, then the save method could be called. There would be no difference between doing this and having no layers in the architecture. Instead of having spaghetti code (where the flow of control is arbitrary) you end up with
spaghetti hoops (where the execution of code is arbitrary).
>> Next Page: Conclusion
<< Back to Design
<< Back to Software Reality