solid-principlessingle-responsibility-principleyagni

Write programs that do one thing and do it well


I can grasp the part "do one thing" via encapsulation, Dependency Injection, Principle of Least Knowledge, and You Ain't Gonna Need It; but how do I understand the second part "do it well?"

An example given was the notion of completeness, given in the same YAGNI article:

for example, among features which allow adding items, deleting items, or modifying items, completeness could be used to also recommend "renaming items".

However, I found reasoning like that could easily be abused into feature creep, thus violating the "do one thing" part.

So, what is a litmus test for seeing rather a feature belongs to the "do it well" category (hence, include it into the function/class/program) or to the other "do one thing" category (hence, exclude it)?

The first part, "do one thing," is best understood via UNIX's ls command as a counterexample for its inclusion of excessive number of flags for formatting its output, which should have been completely delegated to another external program. But I don't have a good example to see the second part "do it well."

What is a good example where removing any further feature would make it not "do it well?"


Solution

  • I see "Do It Well" as being as much about quality of implementation of a function than about the completeness of a set functions (in your example having rename, as well as create and delete).

    Do It Well manifests in many ways, some ways of thinking:

    Behaviour in response to "special" inputs. Example, calculating the mean of some integers:

    int mean(int[] values) { ... }
    

    what does this do if the array has zero elements? If the items total more than MAX_INT?

    Performance Characteristics. Has sufficient attention been given to behaviour as the data volumes increase?

    Dependency Failures. If our implementation depends upon other modules or infrastructure what happens when these fail. Example: File System Full, Database Down?

    Concerning feature creep itself, I think you're correct to indentify a tension here. One thing you might consider: you don't need to implment every feature providing that it's pretty obvious that a feature can be added easily without a complete rewrite.