<?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: Bringing Plausible Deniability to Development: the Strategy Pattern</title>
	<atom:link href="http://www.thycotic.com/bringing-plausible-deniability-to-development-the-strategy-pattern/feed" rel="self" type="application/rss+xml" />
	<link>http://www.thycotic.com/bringing-plausible-deniability-to-development-the-strategy-pattern</link>
	<description></description>
	<lastBuildDate>Mon, 08 Mar 2010 21:25:27 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.3</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: David Cooksey</title>
		<link>http://www.thycotic.com/bringing-plausible-deniability-to-development-the-strategy-pattern/comment-page-1#comment-3884</link>
		<dc:creator>David Cooksey</dc:creator>
		<pubDate>Tue, 18 Aug 2009 20:10:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.thycotic.com/?p=370#comment-3884</guid>
		<description>Tyler,

Good point.

You could certainly do that, though if the decision point remains in code you would just be moving the case statement to another location.  Instead of determining the strategy within the Process function, the strategy would have to be created somewhere within the code that creates the PaymentRequest.

Since we&#039;re adding a new class, we have to specify somewhere, either in code or via configuration, the link between a particular request and its strategy.

In this case we could create a mapping table that links a PaymentTypeId to a strategy class name, in which case we could just use the class name to create an instance of the strategy to use.

That has the benefit of being more configuration-based, and as such it would let you change what strategy to use for each payment type on the fly.

David Cooksey</description>
		<content:encoded><![CDATA[<p>Tyler,</p>
<p>Good point.</p>
<p>You could certainly do that, though if the decision point remains in code you would just be moving the case statement to another location.  Instead of determining the strategy within the Process function, the strategy would have to be created somewhere within the code that creates the PaymentRequest.</p>
<p>Since we&#8217;re adding a new class, we have to specify somewhere, either in code or via configuration, the link between a particular request and its strategy.</p>
<p>In this case we could create a mapping table that links a PaymentTypeId to a strategy class name, in which case we could just use the class name to create an instance of the strategy to use.</p>
<p>That has the benefit of being more configuration-based, and as such it would let you change what strategy to use for each payment type on the fly.</p>
<p>David Cooksey</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tyler Madison</title>
		<link>http://www.thycotic.com/bringing-plausible-deniability-to-development-the-strategy-pattern/comment-page-1#comment-3871</link>
		<dc:creator>Tyler Madison</dc:creator>
		<pubDate>Mon, 10 Aug 2009 20:02:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.thycotic.com/?p=370#comment-3871</guid>
		<description>David, great article and practical explanation. I was wondering if another way to keep from having to edit the switch statement for each new payment type that could be added in the future if you could simply let the PaymentRequest encapsulate which strategy to instantiate? So the process payment code would simply be reduced to:

    private void Process(IPaymentRequest request)
    {
      IPaymentStrategy strategy = request.paymentStrategy;

      double amount = strategy.CalculateAmount(request);
      WriteCheck(amount);

    }


or something similar?

thanks again!

Tyler Madison</description>
		<content:encoded><![CDATA[<p>David, great article and practical explanation. I was wondering if another way to keep from having to edit the switch statement for each new payment type that could be added in the future if you could simply let the PaymentRequest encapsulate which strategy to instantiate? So the process payment code would simply be reduced to:</p>
<p>    private void Process(IPaymentRequest request)<br />
    {<br />
      IPaymentStrategy strategy = request.paymentStrategy;</p>
<p>      double amount = strategy.CalculateAmount(request);<br />
      WriteCheck(amount);</p>
<p>    }</p>
<p>or something similar?</p>
<p>thanks again!</p>
<p>Tyler Madison</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dew Drop &#8211; July 31, 2009 &#124; Alvin Ashcraft's Morning Dew</title>
		<link>http://www.thycotic.com/bringing-plausible-deniability-to-development-the-strategy-pattern/comment-page-1#comment-3860</link>
		<dc:creator>Dew Drop &#8211; July 31, 2009 &#124; Alvin Ashcraft's Morning Dew</dc:creator>
		<pubDate>Fri, 31 Jul 2009 13:23:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.thycotic.com/?p=370#comment-3860</guid>
		<description>[...] Bringing Plausible Deniability to Development: the Strategy Pattern (David Cooksey) [...]</description>
		<content:encoded><![CDATA[<p>[...] Bringing Plausible Deniability to Development: the Strategy Pattern (David Cooksey) [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
