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.

Summary

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.

Discuss this article in the Message Forum...

<< Back to Design

<< Back to Software Reality