[eyelidlessness]

Most of the post resonated with me, but the initial analogy and its concrete example give me pause.

> The dependency (oil, in this example) is an argument, not because anyone cares to customize it, but to simplify the implementation.

This is a huge leap! I know it’s an example, but it’s perfectly reasonable to satisfy both “don’t make me bring oil to the grease monkeys” and “express oil as an explicit dependency of grease monkey activity.” It will, of course, buck some recent discussions here, but the reasonable solution to that is an additional abstraction. And it will of course not buck another long time favorite here: functional core.

1. Provide the convenience interface which defaults to some way of determining a sensible default. In the example case, bringing your own highly configurable oil to the people who change your oil is an exceedingly idiosyncratic case, but for generalization purposes let’s say that’s optional.

2. For all cases, directly provide oil to the processes explicitly dependent on oil to proceed.

+ 3. Make sure you have your dependencies: if the weirdo with super weird oil opinions supplied their own weird oil, you’re done; otherwise get your sensible defaults ready. This is super cool because,

+ 4. Now you can just put oil in the car without making the oil selection everyone’s business (responsibility).

Maybe that’s “simplify[ing] the implementation”, but not in the ways that’s usually meant. It also has the really awesome property of preventing billion dollar mistakes. This:

> Leave the argument nil, and the function will silently leave the object in a bad state.

Doesn’t have to happen, even if your language/environment is predisposed to it. For the cost of a fairly mundane function boundary, you get a convenient interface for users who don’t care about how the oil sausage is made, and free null safety.

> What the caller probably wanted was more like this

I really don’t think that’s a reasonable assumption at all. What the caller probably wanted was more like this:

  func ChangeOil(c Car, oilType OilType) error {
    // There, that’s the whole function body
  }

They don’t care if you also provide a good interface to the mechanics, they care about you managing a business (abstraction) they hired you to take care of for them.

[Cardinal7167]

Go even has a mantra for this: “accept interfaces, return concrete types”. In the example, I would think to design it such that Oil is just an interface with adapters for either user specified oilType or oilInventory or whatever.

[suprfnk]

That seems like a more specific version of Postel’s law/the robustness principle:

“be conservative in what you do, be liberal in what you accept from others"

https://en.m.wikipedia.org/wiki/Robustness_principle

[blowski]

It seemed to me that the whole example was too contrived. The garage could simply have the option to buy the oil and give it to the mechanic.

    func GetOil(oilType OilType) Oil {
        ...
    }

    func ChangeOil(c Car, oil Oil) error {
        ...
    }