## Learn to think De-Coupling

## Contents

Flexibility of metacall based API’s is almost endless. Each metacall based solution delivers bigger freedom to experiment, than a “normal” object+methods solution. And also it forces the programmer to think of decoupling idioms from the start. Which I consider as a very good thing indeed.

One more thing. Each and every metacall based solution does not have to be completely flexible, and ultimately clever. For example, one could pose much more strict rules for the above, and start like so:

1 2 3 4 5 6 7 8 9 10 11 12 13 |
// // option: // change back to strict rules for the callers // euler bench must be constructed with id // of the solution and initial constant input // one instance is made for one solution usage // solution UID is stored until not explicitly erased // limiter is considered a constant in this variant euler_bench("sum_n", 1000 ) (3)(5)(7) // divisors are variables ( compute _and_show_current ) ; // result found by id "sum_n" // |

Above is not all singing and all dancing “workbench”, but still functional and flexible call-stream based solution. We can use our original solution unchanged to “stream in” any number of divisors we want, and then we collect the result.

Now please carefully re-read everything once more up to this point, and try to record how the original simple requirement has changed gradually to be almost dramatically different to what it wa on the beginning.

**Change management is the key**

This example is just an abstract problem, but imagine if it is to be solved and delivered to a paying customer? Who is also a “typical-real-life” customer, who likes to add *and* more importantly remove “details” from requirements?

A typical interaction with a typical customer goes like this. The original requirement might have been:

1 2 3 |
// start date R1 :: make a program to compute the sum of all numbers, which are less than X, and are multiples of Y. |

Then (like us here) customer adds a “detail”, after let’s say two weeks.

1 2 3 4 5 |
// start date + two weeks // R1 becomes R2 R2 :: make a program to compute the sum of all numbers which are less than X, and are multiples of Y1 or Y2 . |

This is perhaps the original problem no 1. But. Mr Customer is unstoppable by now. After 3 days requirements are changed again.

1 2 3 4 5 6 |
// stat date + two weeks + 3 days // R1 become R2, R2 becomes R3 R3 :: make a program to compute the sum of all numbers which are less than X, and are multiples of one or more numbers less than X. |

I am sure this is enough to illustrate the point. Add to the above all the requirements customer will make to “improve” the usability of each solution.

I am sure you understand, and I do not have to paint more of this “reality” picture. And now imagine you do not use a concept and mechanism like metacall is. To implement these changes as improvements would be much more difficult.

And as in real life with real requirements, down the development line, more and more changes are simply impossible to implement. And in the same time call them ‘improvements’.

Now imagine doing this without metacall based solution composed of particles of logic. That, i am sure you know by now, will be a struggle.

–DBJ

(first published 13 Apr 2010)

ps: We can talk about javascript code to implement the above if anyone cares to ask.

pps: We can also talk about c++ code to implement the above if anyone cares to ask :)