Convention over Configuration
From APIDesign
| Line 1: | Line 1: | ||
Due to [[cluelessness]] being present in almost every user of our [[API]], it is better if they don't need to configure anything. It is good if the code [[API]] users create can be analysed automatically and default configuration deduced from it. Modern frameworks (that wish to be [[Good Technology|cool and in]]) rely on this concept quite often as [[wikipedia::Convention_over_configuration|wikipedia says]]. It is however fair to remind us that [[Java]] used [[Convention over Configuration]] sooner then it was invented: the [[JavaBean]] specification relies on it heavily. | Due to [[cluelessness]] being present in almost every user of our [[API]], it is better if they don't need to configure anything. It is good if the code [[API]] users create can be analysed automatically and default configuration deduced from it. Modern frameworks (that wish to be [[Good Technology|cool and in]]) rely on this concept quite often as [[wikipedia::Convention_over_configuration|wikipedia says]]. It is however fair to remind us that [[Java]] used [[Convention over Configuration]] sooner then it was invented: the [[JavaBean]] specification relies on it heavily. | ||
| + | |||
| + | An interesting observation about [[singleton]]s: If you follow the best practice of writing [[singleton]]s that support [[testability]] and extensibility, you end us with [[Injectable Singleton]]s which follow the credo of [[Convention over Configuration]]: The default is easy to use, if you don't like it, you can provide better implementation. | ||
[[Category:APIDesignPatterns]] | [[Category:APIDesignPatterns]] | ||
Current revision
Due to cluelessness being present in almost every user of our API, it is better if they don't need to configure anything. It is good if the code API users create can be analysed automatically and default configuration deduced from it. Modern frameworks (that wish to be cool and in) rely on this concept quite often as wikipedia says. It is however fair to remind us that Java used Convention over Configuration sooner then it was invented: the JavaBean specification relies on it heavily.
An interesting observation about singletons: If you follow the best practice of writing singletons that support testability and extensibility, you end us with Injectable Singletons which follow the credo of Convention over Configuration: The default is easy to use, if you don't like it, you can provide better implementation.
Anyone knows older use of Convention over Configuration?
<comments/>
Follow
