4 ms·
This is quite naive. When I learned to drive, my tester required that I demonstrate competence with the controls, using them at the appropriate times, in the a
by jeremysmyth 13y ago
This is quite naive.
When I learned to drive, my tester required that I demonstrate competence with the controls, using them at the appropriate times, in the appropriate ways.
If my car exposed all of its private internal operations, I would have needed to know how to use them, and demonstrated that I know that. I haven't a clue about fuel flow and gear ratios, or air/fuel mixture or how the thermostat affects how the engine operates. I'm quite happy that I didn't have to demonstrate all of that too.
What the article ignores is that a good API provides everything the consumer needs, while keeping the API small and easily comprehensible. A driver who has to keep track of 5 details is more likely to learn to use his car more quickly, and less likely to crash than one who has to keep track of 200 details and make decisions about each one.
- tomp 13y agoYou give a great analogy, but IMO extract the wrong conclusions. The car exactly follows the philosophy outlined in this article; the driver/user doesn't need to know the internals, but you can always open up the hood and adjust/fix/modify the inner working.
- sz4kerto 13y agoThere's one problem with the analogy - exactly the point what you're trying to use... a car is almost never updated. There's no patch for the turbocharger, the piston design stays the same after manufacturing, etc. So it's OK to retrofit a custom turbocharger.
- spacelizard 13y agoNot true. Every now and then you'll see a car recalled because of manufacturing or design defects.
- jasonkarns 13y agoThere is a strong difference between exposing everything as part of the API, and making it permanently inaccessible. Taking your car example, imagine if the engine were in a locked black box. Any modifications or changes necessary would require replacing or duplicating the ENTIRE ENGINE. Instead, those with the proper know-how, can get under the hood when necessary. Making the engine accessible doesn't force drivers to know everything about it. It's hidden, but accessible when needed.
- jeremysmyth 13y agoTo round-trip this analogy, I can't edit the source code of a system library or purchased component unless I have the source, and have the rights to edit it, neither of which are a given in today's world. Sure, an epoxy-encased engine isn't going to let me tinker with it, but I will never tinker with my engine. That's one of the wonderful things about separation of concerns that OO gives me, including all the perceived badness of enforced privacy: I can work on my particular thing without needing to know anything about the innards, because it is not my responsibility to do so, neither explicitly through delegation of concern and documentation, or implicitly through presentation of a semi-private API. If I'm able to see it, then I'm expected to see it, and that blurs the lines of the API.
- philjackson 13y agoYou would have had to know how the internals work? Why? I often hear people nostalgically talking about how it was better in the olden days when people could fix/tweak their engines as they wished. If you lift the bonnet of my car it's a sheet of plastic and a few colour-coordinated filler lids so that I can top-up fluids. No hackability whatsoever.
- nathan_long 13y agoYou're right, but you misunderstand the OP. Ruby, for example, has "advisory privacy". Private methods aren't shown in generated documentation but can be called if you really want. On your analogy, the car has a small number of controls visible and they're all you need 99% of the time. But the engine compartment isn't welded shut.