3 ms·
This "layered" effect of interface hiding is natural in pure functional contexts. In Haskell you often see exposed "Internal" modules for just this reason---the
by tel 13y ago
This "layered" effect of interface hiding is natural in pure functional contexts. In Haskell you often see exposed "Internal" modules for just this reason---they're not the primary API, but they're valuable to have around.
It's harder to have these layered effects in other languages (in my experience) though often distinctions between a concrete and abstract (interface driven) API are a good first layer.
- Chris_Newton 13y agoThere is a lot of merit in allowing modules to offer multiple interfaces that clients can use as long as they explicitly request them. You can solve the multiple-levels-of-abstraction API problem that way, and you can solve production/test/debug access control problems that way too. Unfortunately, most languages today have at best limited support for this idea. For example, plenty of languages with OOP tools offer both some sort of public/private distinction for access control and a concept of implementing one or more explicit interfaces, but these are usually treated as orthogonal features. As long as you’re working in that kind of framework, or with more dynamic tools where you don’t necessarily have any concept of explicit interfaces at all, it’s going to be difficult to write unit tests without circumventing the normal access control and modularity mechanisms somehow.