Software Reality
Programming with
a dose of satire.

Site Map Search

Agile Development
Extreme Programming
Code Generation


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.


Interface Design

<< LIGHT Data and Architectures

Page 8: Conclusion

Anorexic Interfaces

The argument for exposing LIGHT interfaces at the architectural level does not mean the lighter the better.

For example, there is a class of programmer that uses the key/value pair model because of its flexibility, and ability to adapt to changing requirements. Key/Value pairs have their place within implementations, such as Hashtables, Properties, or Message values.

However, exposing key/value pairs at the architectural level leads to ambiguity and confusion. Type safety is eliminated. Programmers have no explicit object model and have to rely on metadata. To regain some control over the code, additional anti-patterns must be added to handle type validation and conversion, in effect re-implementing the functions of the compiler and VM, and creating the most impoverished of languages.


In summary, it is important to make a decision about what style of class you are building, and that that decision should be communicated between your programmers so that these components can later be integrated more easily. The File classes above show that if the types of class differ significantly, there would have to be a lot of extra code written to interface between them.

When programmers write code, they often have brief conflicts in their mind: Should I do this or that? Should I use a file or a String as an argument?

Instead, the question must be: is this class a Utility, Service, Object or Component, and at what level should it be exposed?

Each type of class has its place.

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