Software Reality
Programming with
a dose of satire.

Site Map Search


Agile Development
 
Extreme Programming
 
Code Generation


Articles
Lifecycle
Design
Programming
Soapbox
Reviews
Cthulhu

Check out our ageing Reviews Section


Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:



ICONIX/Sparx Public Classes to Come to London

ICONIX is planning a series of open- enrollment public classes entitled Hands-On Enterprise Architect for Power Users in collaboration with Sparx Systems.




Design

Interface Design

<< 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.

LIGHT Architecture
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.

GOTO Objects

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

All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright 1998 onwards Matt Stephens. ALL RIGHTS RESERVED.