Don't write another line code until you have seen this
I think this talk is one of the best talk I have found in Googles Engineering series. Google talks are generally very good, but this is even better and has a good speaker.
Joshua Bloch talk "How To Design A Good API and Why it Matters" presents a lot of good information what to think about when creates API:s. Even if you aren't writing another framework it is important. I think people seems to believe today that reuse can only be done using frameworks. Joshua points out the importance of good API:s inside your program and for different modules.
I would also like to add that this is important when designing new XML-DTD:s, which is a kind of API. For instance, I have seen XML file formats that says the address-tag includes space separated e-mail addresses. Why not use multiple address-tags, one for each address. In this way I can solely use my XML-parser to parse the file and do not need add extra code to separate the sting at spaces.
If you do not have an hour at the moment, remember this points which I have taken from the talk:
A very good book on the same topic is "Object-Oriented Design Heuristics" by Riel.
Joshua Bloch talk "How To Design A Good API and Why it Matters" presents a lot of good information what to think about when creates API:s. Even if you aren't writing another framework it is important. I think people seems to believe today that reuse can only be done using frameworks. Joshua points out the importance of good API:s inside your program and for different modules.
I would also like to add that this is important when designing new XML-DTD:s, which is a kind of API. For instance, I have seen XML file formats that says the address-tag includes space separated e-mail addresses. Why not use multiple address-tags, one for each address. In this way I can solely use my XML-parser to parse the file and do not need add extra code to separate the sting at spaces.
If you do not have an hour at the moment, remember this points which I have taken from the talk:
- When in doubt, leave it out
- Don't make the client do anything that the module could do
A very good book on the same topic is "Object-Oriented Design Heuristics" by Riel.
Comments