justification: reduce source change, which can introduce bugs
justification: reduce test effort
justification: Maintain users’, bosses’ and colleagues’ confidence. Confidence that the source didn’t change, so existing functionalities aren’t affected.
justification: slightly Better man-day estimate compared to hacking source code
justification: Adaptble, Flexible
justification: more readable than source code
justification: something of a high-level documentation, well-structured
Examples: DD, spring config file, struts config file, hibernate config file.
I feel this is a habit (unit test is another habit). Initially it’s not easy to apply this idea. A lot of times you feel “not applicable here”, only to witness others applying it here. Easier to justify for component-based, inter-dependent modules. Other projects may find declarative control an overkill, and may opt for a properties file.
Q: Alternative to declarative?
A: The information must move into some place, usually source code. How about a properties file?
Q: is this a design pattern?
A: Purists to avoid the term. For OO and non-OO