'. '

ConfigurationObject

From APIDesign

Revision as of 10:28, 22 February 2015 by JaroslavTulach (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

ConfigurationObject pattern is often used by JavaScript libraries to deal with evolution in a manageable way. While TheAPIBook advocates being ready for first version never be perfect, people repeat the same design mistakes again and again. Usual evolution history starts with introducing method with one argument: 

function upper(text) {
  return text.toUpperCase();
}
upper("Hello World!") == "HELLO WORLD!"

then one finds out additional argument is needed: 

function upper(text, firstLetterOnly) {
  if (firstLetterOnly) {
    return text.substring(0, 1).toUpperCase() + text.substring(1);
  }
  return text.toUpperCase();
}
upper("hello world!") == "HELLO WORLD!"
upper("hello world!", true) == "Hello world!"

and later another one, and another and so on, until one realizes the whole API is total mess and it is time to switch to ConfigurationObject: 

function upper(data) {
  if (data.firstLetterOnly) {
    return text.substring(0, 1).toUpperCase() + text.substring(1);
  }
  return data.text.toUpperCase();
}
upper({ 
  "text" : "hello world!",
  "firstLetterOnly" : false
}) == "HELLO WORLD!"
upper({ 
  "text" : "Hello World!",
  "firstLetterOnly" : true
}) == "Hello world!"

Adding named parameters is more easily evolvable. Moreover it is certainly easier to use ten named arguments than a function with ten parameters.

Retrieved from "http://wiki.apidesign.org/wiki/ConfigurationObject"
Personal tools
buy