Click here to Skip to main content
13,860,894 members
Click here to Skip to main content
Add your own
alternative version

Tagged as


3 bookmarked
Posted 4 Mar 2012
Licenced CPOL

Tame Application Flexibility By Loose Coupling With Object Decoration

, 11 Mar 2012
Rate this:
Please Sign up or sign in to vote.
Discuss application flexibility of static typing.

When talking about application flexibility, the first thing you would think of probably is dynamic typing. However, dynamic typing is evil in a way that it is too flexible to maintain correctness, safety and predictability. Defensive coding and testing may alleviate the issues to some degree. But, how much defensive code is enough? How many tests are enough? The answers are probably “never enough” or “don’t know”. Plus, defensive code is ugly!

Static typing is evil in the opposite way that it is too inflexible to adapt to changes. Static typing is infamous in its rigidity and inflexibility to changes. That should not be the case, though! With loose coupling and object decoration, static typing is readily adaptive to changes.

Loose coupling is not new and is a great idea coming out of static typing. But for some reason, it has been underused. A system initially loosely-coupled is often quickly turned into tightly-coupled due to lack of follow-throughs to support it (mentally or technologically). With the advent of object decoration, behaviors can be added at runtime to a loosely-coupled system. Loose coupling forms a basis for adding dynamic behaviors – behaviors at runtime, which effectively make a software system adapt to changes. Vice versa, putting changes in dynamic behaviors makes a software system remain loosely-coupled. Object decoration technologically makes loose coupling possible over the course of evolving of a software system.

Loose coupling is based on interface, with which a client does not need to know about the inner workings of a component in order to make use of it. By programming to interface, the client is completely decoupled from the implementation of a component. Consequently, a component can replace another (at design time or runtime) as long as the successor component implements the same interface as the initial component without breaking the system in which the component operates.

Here is how loose coupling with object decoration adapts to changes. As new requirements come in, dynamic behaviors are created for them. The dynamic behaviors are, then, attached to methods of interface at runtime as needed. There is no need to modify the existing components. It is pure client-side coding.

In case of a new release of components, they can be just dropped into the client application as long as they keep their interfaces. The client application gets the new features of the components automatically.

This way, the client evolving and component enhancement are completely separated. And best of all, the system stays loosely-coupled. With the support of dynamic behaviors, it is possible to design a truly loosely-coupled software system. In the end, the loose coupling is not just an ideal, it is a reality.

Now it is time to mentally get ready for design of loosely-coupled system. Actually, loosely-coupled design is very simple. You design client contract (interfaces), implement them in your components, and program to these interfaces in client application, then, add extra behaviors at runtime with object decoration as needed based on requirements or changes of requirements. That’s it.

The important point here is add behaviors at runtime with object decoration instead of adding behaviors at design time with classes. That is the reason why a loosely-coupled system can stay loosely-coupled. Furthermore, why do you need class if method (dynamic behavior is method) can solve the problem? And, remember that some dynamic typing languages live without class!

As final notes, I would like to say a few words on flexibility. By now, you would agree that flexibility is possible with both static typing and dynamic typing in terms of adding behaviors at runtime. However, the mechanism used by static typing is different from dynamic typing. In static typing, the flexibility is achieved by loose coupling with object decoration, therefore, safe and predictable. On the other hand, the flexibility in dynamic typing is achieved by altering object types, therefore, unsafe and unpredictable.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Gary H Guo
United States United States
Object-oriented (OO) is about "classes" not "objects". But I truly believe that "objects" deserve more our attentions. If you agree, read more on... Dynamic Object Programming (DOP), Component-Based Object Extender (CBO Extender), AOP Container and Dynamic Decorator Pattern.

Mobile development is not just another type of front end. The real challenge is actually in the back end: How to present meaningful information in time to mobile users with exponentially increased data flooding around? Here is my first mobile solution: SmartBars - Barcode Reader, Price Comparison and Coupons.

Gary lives in southeast Michigan. My first programming language is FORTRAN. For the last a few years, I have primarily focused on .NET technologies with Mobile Development as my newest interest.

You may also be interested in...


Comments and Discussions

SuggestionExamples Pin
Daniel Joubert5-Mar-12 0:59
professionalDaniel Joubert5-Mar-12 0:59 
GeneralRe: Examples Pin
Gary H Guo5-Mar-12 2:21
memberGary H Guo5-Mar-12 2:21 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web01 | 2.8.190214.1 | Last Updated 11 Mar 2012
Article Copyright 2012 by Gary H Guo
Everything else Copyright © CodeProject, 1999-2019
Layout: fixed | fluid