<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.msdn.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Krzysztof’s Laws of API Design</title><link>http://blogs.msdn.com/kcwalina/archive/2005/12/20/APIDesignLaws.aspx</link><description>I always thought about writing down the laws of APIs design. By "laws", I mean principles that don’t seem to change based on the particular scenario at hand, whether the API is low of high level, etc. Here is my first try. I would appreciate any comments</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP1 (Build: 61025.2)</generator><item><title>re: Krzysztof’s Laws of API Design</title><link>http://blogs.msdn.com/kcwalina/archive/2005/12/20/APIDesignLaws.aspx#506066</link><pubDate>Tue, 20 Dec 2005 23:11:14 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:506066</guid><dc:creator>Diego Mijelshon</dc:creator><description>If I understood correctly, applying laws 1, 2 and 3, the best class library in the world has:&lt;br&gt;one namespace&lt;br&gt;with one type&lt;br&gt;that has one member&lt;br&gt;with one parameter.&lt;br&gt;&lt;br&gt;Or a member without parameters&lt;br&gt;or no members&lt;br&gt;or just an empty class library.&lt;br&gt;&lt;br&gt;Sorry, I couldn't resist :-)</description></item><item><title>re: Krzysztof’s Laws of API Design</title><link>http://blogs.msdn.com/kcwalina/archive/2005/12/20/APIDesignLaws.aspx#506085</link><pubDate>Tue, 20 Dec 2005 23:57:49 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:506085</guid><dc:creator>tzagotta</dc:creator><description>I think you are expressing a pretty cynical or jaded view of API design.  The theme of these laws is &amp;quot;less is more&amp;quot; - but the tension is that at the same time we know that less is less.  In other words, usability is a function of both learnability (less is more) and functionality (less is less, or more is more).  Therefore, usability is probably more like a curve that starts at zero, climbs up as more stuff is added, but converges at some kind of maximum, or at a minimum, has diminishing marginal returns.</description></item><item><title>re: Krzysztof’s Laws of API Design</title><link>http://blogs.msdn.com/kcwalina/archive/2005/12/20/APIDesignLaws.aspx#506135</link><pubDate>Wed, 21 Dec 2005 02:23:02 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:506135</guid><dc:creator>kcwalina</dc:creator><description>These are fair comments; I should have clarified what I mean by &amp;quot;usability.&amp;quot; When I say &amp;quot;usability,&amp;quot; I mean &amp;quot;how easy to use the library is&amp;quot;. Overall goodness (utility?) of a library is some combination of usability and functionality.</description></item><item><title>re: Krzysztof’s Laws of API Design</title><link>http://blogs.msdn.com/kcwalina/archive/2005/12/20/APIDesignLaws.aspx#506364</link><pubDate>Wed, 21 Dec 2005 19:19:20 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:506364</guid><dc:creator>Skip Sailors</dc:creator><description>In summary, write the least code that meets the requirements.  If a package with no namespaces, no types, and no members works for the client, ship it!</description></item><item><title>re: Krzysztof’s Laws of API Design</title><link>http://blogs.msdn.com/kcwalina/archive/2005/12/20/APIDesignLaws.aspx#507451</link><pubDate>Tue, 27 Dec 2005 03:41:39 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:507451</guid><dc:creator>Norman Sasono</dc:creator><description>Note that KC focuses on API or publicly accessible parts (Type, Member, etc) of a framework or library. It doesn't deal much with the internal object model of the framework or library.&lt;br&gt;&lt;br&gt;Internally, the public Types or Members of a framework or library may delegates the works to other internal or private Types or Members; Adapter objects, Command Objects, Strategy Objects, etc... just like the long live OO design.</description></item><item><title>re: Krzysztof’s Laws of API Design</title><link>http://blogs.msdn.com/kcwalina/archive/2005/12/20/APIDesignLaws.aspx#508218</link><pubDate>Fri, 30 Dec 2005 19:28:06 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:508218</guid><dc:creator>Sam</dc:creator><description>I was wondering if you could recommend any additional reading material (online or offline)that goes into the details of good API design?&lt;br&gt;&lt;br&gt;I come from a web dev background and I'm moving more &amp;amp; more into the web services arena with C# so this sort of area is pretty new to me and I'd like to make sure my work is as clean as possible.&lt;br&gt;&lt;br&gt;Cheers.</description></item><item><title>Link Roundup</title><link>http://blogs.msdn.com/kcwalina/archive/2005/12/20/APIDesignLaws.aspx#665313</link><pubDate>Fri, 14 Jul 2006 08:30:11 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:665313</guid><dc:creator>Life, Universe and Everything according to Dirk</dc:creator><description>Here's one more collection of links.&amp;amp;amp;nbsp; It took me quite a while, and I threw out 90% of the links...</description></item><item><title>re: Krzysztof’s Laws of API Design</title><link>http://blogs.msdn.com/kcwalina/archive/2005/12/20/APIDesignLaws.aspx#935316</link><pubDate>Thu, 02 Nov 2006 22:12:30 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:935316</guid><dc:creator>Rushabh</dc:creator><description>&lt;p&gt;WOW. This is so, so, so true, and succint and precise. &lt;/p&gt;
&lt;p&gt;I feel that every developer should take the &amp;quot;laws&amp;quot; print it out and stick it on a wall in front of her monitor. (I certainly did)&lt;/p&gt;
&lt;p&gt;Thanks Krzysztof!&lt;/p&gt;</description></item><item><title>Krzysztof??Ts Laws of API Design</title><link>http://blogs.msdn.com/kcwalina/archive/2005/12/20/APIDesignLaws.aspx#8992359</link><pubDate>Thu, 09 Oct 2008 05:41:50 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:8992359</guid><dc:creator>IWebThereforeIAm</dc:creator><description>&lt;p&gt;Krzysztof Cwalina's Laws of API Design...&lt;/p&gt;
</description></item><item><title>re: Krzysztof’s Laws of API Design</title><link>http://blogs.msdn.com/kcwalina/archive/2005/12/20/APIDesignLaws.aspx#9858441</link><pubDate>Thu, 06 Aug 2009 00:49:52 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:9858441</guid><dc:creator>Robert</dc:creator><description>&lt;p&gt;I'd like another one: The usability of an API is directly related to the quality of its documentation which is expressed in the length of sentences and the number of substantives per sentence. Err, I mean, write the documentation for programmers, not for lawyers.&lt;/p&gt;</description></item></channel></rss>