A good interface is one that allows the user to accurately assess the tradeoffs involved in using this program over some other solution.<p>In this vein any interface that requires you instantiate all kinds of library-specific structs just to call the relevant function, and conversely upon return, is hiding the actual surface area of the interaction boundary. This makes the aforementioned asessment harder.<p>This can of course be a justified tradeoff for intended use cases, and this is brings me to my point: An interface author must conscientiously and deliberately adapt the interface to intended use cases.<p>The user, on the other hand, cannot peer into the mind of the interface author and must measure the analogous intent and purpose of a given interface in the context of his particular requirements.<p>A good interface, then, is one which the author has designed and documented so that prospective users<p>(1) accurately determine its suitability to their specific use case,<p>and (2) are not suprised if and when they decide to make use of it.<p>Changing the intended use case by exposing or hiding configurability, inverting control or establishing «sane» defaults is a red herring. It has no bearing on the goodness of the interface. Goodness comes from wether configurabiliy, inversion or defaults are apparent to the user.<p>Edit: spelling/phrasing
Good interfaces should primarily have reasonable and well documented pre and post conditions. This is very apparently not so in the oil change example in the article.<p>It's completely stunning to me how frequently this is forgotten in spite of having been a key component of object oriented programming when it was invented (ie smalltalk days, before I was born).
Most of the post resonated with me, but the initial analogy and its concrete example give me pause.<p>> The dependency (oil, in this example) is an argument, not because anyone cares to customize it, but to simplify the implementation.<p>This is a <i>huge leap</i>! 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 <i>not</i> buck another long time favorite here: functional core.<p>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.<p>2. For all cases, directly provide oil to the processes explicitly dependent on oil to proceed.<p>+ 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,<p>+ 4. Now you can just put oil in the car without making the oil selection everyone’s business (responsibility).<p>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:<p>> Leave the argument nil, and the function will silently leave the object in a bad state.<p>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, <i>and</i> free null safety.<p>> What the caller probably wanted was more like this<p>I really don’t think that’s a reasonable assumption at all. What the caller probably wanted was more like this:<p><pre><code> func ChangeOil(c Car, oilType OilType) error {
// There, that’s the whole function body
}
</code></pre>
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.
My first question was, where does “inventory.GetOil()” come from. Is this just a package that wasn’t mentioned? Not being a Go expert, are packages typically global like this? Would that be a good way to implement this function/method (in a package that then becomes available everywhere in main() as opposed to passing it)?<p>Ah, well, maybe I missed the point entirely.
Off topic : I love this font. Looks so good, especially for code.<p>Font is Inconsolata (<a href="https://fonts.google.com/specimen/Inconsolata" rel="nofollow">https://fonts.google.com/specimen/Inconsolata</a>)
An interface is a contract. It shouldn't be concerned with implementation details and it should contain the absolute minimum to do the work.<p>public ResultType ChangeOil(Car c, Oil oil = null); is enough.<p>In the actual implementation of the interface we can check if oil is null and if it is, provide own oil which fits car. If oil is not null, we can check if it is enough and if the type fits car type.<p>We also can return a car with changed oil and an error.<p>However the user of the interface shouldn't be concerned with actual implementation details. The same way an user of a Web API shouldn't be concerned with actual implementation detail.
Check this book by David Hanson, C Interfaces and Implementations: Techniques for Creating Reusable Software:<p><a href="https://drh.github.io/cii/" rel="nofollow">https://drh.github.io/cii/</a><p>Example codes:<p><a href="https://github.com/drh/cii">https://github.com/drh/cii</a>
ChangeOil is an awful example. Your “better” code is untestable.<p>And ChangeOil(car, nil) makes complete sense to remove all the car’s oil: in Go, a nil slice is (essentially) equivalent to [].
Don't mean to be uncharitable, but the author seems unaware of basic FP concepts. There's a reason why most OO languages are moving more and more towards FP.
why not just check the array if it's empty? post doesn't give a good example.<p>I argue that the "better way" has more conceptual overhead. if this was a large project. just changing oil would require to understand many ideas.