| A good interface is one that allows the user to accurately assess the tradeoffs involved in using this program over some other solution. 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. 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. 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. A good interface, then, is one which the author has designed and documented so that prospective users (1) accurately determine its suitability to their specific use case, and (2) are not suprised if and when they decide to make use of it. 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. Edit: spelling/phrasing |