When I was growing up my brother and I each had a train set.
My brother’s was a Hornby set. It was very realistic and the trains looked amazing with superb attention to detail. However, if he wanted a different train for a different purpose he had to buy an additional train – a different model. Hornby trains are like closed applications. Very well crafted, good at what they do but not adaptable.
I on the other hand had a Lego 7745. This beautiful red set was built from the familiar lego bricks. One minute it could be a sleek, dashing European Inter-city train speeding between Paris and Hamburg. The next it could be an industrial steam engine (with a much better station!). Beyond the those two possibilities in the instruction manual that it could be anything I wanted it to be that I could make with the bricks I had to fit together. This train was not so completely polished but was functional, attractive in different ways and mutable.
I remembered these two train sets when I read Daniel’s post on APIs and his pulling out of the defining feature of APIs as being a “set of functionalities”.
In this analogy a train set is an application (perhaps the tracks are data but I may be pushing it!) and lego bricks are APIs. APIs can be used in different combinations to build different applications. To use some UML class terms, an application built with APIs is an aggregate of their functionalities and can be refactored to meet different needs; and application not built with APIs is composed of its functionalities and needs to be replaced to meet different needs.