3 ms·

Interview questions I have never been asked, Episode I

5 points by bdfh42 18y ago

Allocator2008 18y ago
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.
LogicHoleFlaw 18y ago
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.

3 ms·

Interview questions I have never been asked, Episode I

5 points by bdfh42 18y ago

Allocator2008 18y ago
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.
LogicHoleFlaw 18y ago
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.