<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Coding: Weak/Strong APIs</title>
	<atom:link href="http://www.markhneedham.com/blog/2009/04/27/coding-weakstrong-apis/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.markhneedham.com/blog/2009/04/27/coding-weakstrong-apis/</link>
	<description>Thoughts on Software Development</description>
	<lastBuildDate>Sat, 11 Feb 2012 23:17:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Book Club: Arguments and Results (James Noble) at Mark Needham</title>
		<link>http://www.markhneedham.com/blog/2009/04/27/coding-weakstrong-apis/comment-page-1/#comment-18733</link>
		<dc:creator>Book Club: Arguments and Results (James Noble) at Mark Needham</dc:creator>
		<pubDate>Tue, 16 Jun 2009 13:38:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.markhneedham.com/blog/?p=1173#comment-18733</guid>
		<description>[...] of this approach is that we make it more difficult for clients to use our API. I think this was best summed up in a comment on a post I wrote about using weak or strong APIs by [...]</description>
		<content:encoded><![CDATA[<p>[...] of this approach is that we make it more difficult for clients to use our API. I think this was best summed up in a comment on a post I wrote about using weak or strong APIs by [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Eric</title>
		<link>http://www.markhneedham.com/blog/2009/04/27/coding-weakstrong-apis/comment-page-1/#comment-15672</link>
		<dc:creator>Eric</dc:creator>
		<pubDate>Thu, 30 Apr 2009 01:22:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.markhneedham.com/blog/?p=1173#comment-15672</guid>
		<description>The choice is between passing (1) what the client probably has on hand already (the pieces) vs. passing (2) what the class demands (a pre-formed object). Which serves the client better and more naturally? 

Which brick-and-mortar shop gets more business--the one taking credit cards (already in the customers&#039; hands), or the one demanding cash in some foreign currency (which the customers first have to go get)? 

Subordinate the service&#039;s convenience to the client&#039;s. Accept what a client likely has at the ready. (At the least, offer an overloaded constructor that does so.)</description>
		<content:encoded><![CDATA[<p>The choice is between passing (1) what the client probably has on hand already (the pieces) vs. passing (2) what the class demands (a pre-formed object). Which serves the client better and more naturally? </p>
<p>Which brick-and-mortar shop gets more business&#8211;the one taking credit cards (already in the customers&#8217; hands), or the one demanding cash in some foreign currency (which the customers first have to go get)? </p>
<p>Subordinate the service&#8217;s convenience to the client&#8217;s. Accept what a client likely has at the ready. (At the least, offer an overloaded constructor that does so.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Maciek Szymanski</title>
		<link>http://www.markhneedham.com/blog/2009/04/27/coding-weakstrong-apis/comment-page-1/#comment-15467</link>
		<dc:creator>Maciek Szymanski</dc:creator>
		<pubDate>Mon, 27 Apr 2009 12:43:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.markhneedham.com/blog/?p=1173#comment-15467</guid>
		<description>Hi Mark,

I&#039;m in favor of the former API, too. As a TDD very (very) beginer I&#039;d say mocking PropertyDifference and putting PropertyDifferences under test would be much easier for me. PropertyDifferences seems to be ordinary collection, some place to store object differences, so I woudn&#039;t expect its responsibility to &#039;create&#039; but to &#039;operate on&#039; its items. The later API also suggests that PropertyDifference can not exist without PropertyDifferences, that PropertyDifference is only valid within PropertyDifferences. Maybe that&#039;s just my feeling.

Maciek</description>
		<content:encoded><![CDATA[<p>Hi Mark,</p>
<p>I&#8217;m in favor of the former API, too. As a TDD very (very) beginer I&#8217;d say mocking PropertyDifference and putting PropertyDifferences under test would be much easier for me. PropertyDifferences seems to be ordinary collection, some place to store object differences, so I woudn&#8217;t expect its responsibility to &#8216;create&#8217; but to &#8216;operate on&#8217; its items. The later API also suggests that PropertyDifference can not exist without PropertyDifferences, that PropertyDifference is only valid within PropertyDifferences. Maybe that&#8217;s just my feeling.</p>
<p>Maciek</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rafael Peixoto de Azevedo</title>
		<link>http://www.markhneedham.com/blog/2009/04/27/coding-weakstrong-apis/comment-page-1/#comment-15462</link>
		<dc:creator>Rafael Peixoto de Azevedo</dc:creator>
		<pubDate>Mon, 27 Apr 2009 11:20:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.markhneedham.com/blog/?p=1173#comment-15462</guid>
		<description>Hi, Mark

What really called my attention is the reference to property names and property values at this point. 

I expect this detailed information to be already abstracted by a Property value object, so the question would be to use Property objects or PropertyDifference objects in the API.

Cheers, Rafael</description>
		<content:encoded><![CDATA[<p>Hi, Mark</p>
<p>What really called my attention is the reference to property names and property values at this point. </p>
<p>I expect this detailed information to be already abstracted by a Property value object, so the question would be to use Property objects or PropertyDifference objects in the API.</p>
<p>Cheers, Rafael</p>
]]></content:encoded>
	</item>
</channel>
</rss>

