

Interview questions I have never been asked, Episode I - bdfh42
http://weblog.raganwald.com/2008/06/interview-questions-i-have-never-been.html

======
LogicHoleFlaw
Oooh, good question. I certainly don't have a definitive answer. My current
preference is to have a few atomic composable methods in a vocabulary. If I
find myself using a specific compositional idiom enough that it needs its own
name, I create a new method and factor out that idiom. I use this strategy
when writing libraries for my own use.

When distributing to others there are more concerns in play. In a language
like Java where 3rd party libraries are frozen from the perspective of the
developer a rich vocabulary is a helpful thing. In Ruby, open classes make it
much easier for the developer to add things on their own. Lua aspires to
minimalism; its standard libary is _very_ small and atomic. Lisp is a very
compositional language so I would lean towards exposing only the key concepts
of a library. These are all valid approaches in their spheres.

------
Allocator2008
I'd probabl have to argue in favor of writing convenience methods to make a
usable api right off the bat. For example, I don't necessarily NEED the strlen
method, since I can make my own with little trouble, but it is sure nice to
have. I'd say the more public methods there are in one's API the better. This
way in the java world, you can have a public interface with all the methods a
client developer could ever want, but protect (hide) the implementation of
these methods. Without a good set of available public api methods, you a)
inconvenience the target developer and b) make it impossible to hide the
implementation, since to do anything useful with the application, the
developer would need to know the "guts" of it, since the public api isn't
good. So yes, probably this is a matter of taste, but in the spirit of "do
unto others", personally I like having "conveniences" like the strlen example,
and so I like to make similar "conveinces" when I'm writing code myself.

