<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://www.eiffelroom.com" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>eiffelroom - Implementing CQS - Comments</title>
 <link>http://www.eiffelroom.com/blog/colin_adams/implementing_cqs</link>
 <description>Comments for &quot;Implementing CQS&quot;</description>
 <language>en</language>
<item>
 <title>Implementing CQS</title>
 <link>http://www.eiffelroom.com/blog/colin_adams/implementing_cqs</link>
 <description>&lt;p&gt;When I first learned Eiffel, I learned the design pattern for getting results back from commands - storing the result in an attribute of the class being changed. And I dutifully followed it religously.&lt;/p&gt;

&lt;p&gt;More recently, I have encountered situations where this pattern seems to be undesirable. If the command can be re-invoked recursively, then things can get tricky.&lt;/p&gt;

&lt;p&gt;In these situations, I am increasingly turning to output arguments instead. So I pass a DS_CELL [G] where G is the type of result I am interested in. The pre-conditions for the command include that the cell is non-Void, but the contents is Void. The post-condition (probably) declares the contents of the cell to be non-Void.&lt;/p&gt;

</description>
 <comments>http://www.eiffelroom.com/blog/colin_adams/implementing_cqs#comments</comments>
 <category domain="http://www.eiffelroom.com/tag/cqs">CQS</category>
 <pubDate>Thu, 15 Mar 2007 01:10:53 -0700</pubDate>
 <dc:creator>colin-adams</dc:creator>
 <guid isPermaLink="false">143 at http://www.eiffelroom.com</guid>
</item>
</channel>
</rss>
