<?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: PTOM: The Open Closed Principle</title>
	<atom:link href="http://lostechies.com/joeocampo/2008/03/21/ptom-the-open-closed-principle/feed/" rel="self" type="application/rss+xml" />
	<link>http://lostechies.com/joeocampo/2008/03/21/ptom-the-open-closed-principle/</link>
	<description>Tales from the field...</description>
	<lastBuildDate>Sat, 11 Feb 2012 08:43:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.4.2</generator>
	<item>
		<title>By: Ravi Mukkavilli</title>
		<link>http://lostechies.com/joeocampo/2008/03/21/ptom-the-open-closed-principle/#comment-903</link>
		<dc:creator>Ravi Mukkavilli</dc:creator>
		<pubDate>Thu, 05 Jan 2012 16:41:00 +0000</pubDate>
		<guid isPermaLink="false">/blogs/joe_ocampo/archive/2008/03/21/ptom-the-open-closed-principle.aspx#comment-903</guid>
		<description>Great post. Internet is lacking examples like these on OOD principles. One question though. Is there any reason to create a Filter method in ProductFilterSpecification class when we can as well expose ApplyFilter method. </description>
		<content:encoded><![CDATA[<p>Great post. Internet is lacking examples like these on OOD principles. One question though. Is there any reason to create a Filter method in ProductFilterSpecification class when we can as well expose ApplyFilter method. </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: DavidS</title>
		<link>http://lostechies.com/joeocampo/2008/03/21/ptom-the-open-closed-principle/#comment-840</link>
		<dc:creator>DavidS</dc:creator>
		<pubDate>Tue, 12 Apr 2011 07:06:00 +0000</pubDate>
		<guid isPermaLink="false">/blogs/joe_ocampo/archive/2008/03/21/ptom-the-open-closed-principle.aspx#comment-840</guid>
		<description>@Joe - Hi can you explain why the separation of concern principle has been violated in your example and also why it matters?</description>
		<content:encoded><![CDATA[<p>@Joe &#8211; Hi can you explain why the separation of concern principle has been violated in your example and also why it matters?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe Ocampo</title>
		<link>http://lostechies.com/joeocampo/2008/03/21/ptom-the-open-closed-principle/#comment-390</link>
		<dc:creator>Joe Ocampo</dc:creator>
		<pubDate>Wed, 26 Mar 2008 20:04:56 +0000</pubDate>
		<guid isPermaLink="false">/blogs/joe_ocampo/archive/2008/03/21/ptom-the-open-closed-principle.aspx#comment-390</guid>
		<description>@Christopher

&gt;I know I&#039;m being a little silly, but I do think that in certain cases the principles can (seem to) be fuzzy and conflicting. Especially for newcomers.

Well it depends...  The principles are meant to guide you in creating better software. Maintainability is only one aspect of great software.  TDD promotes DRY and YAGNI mindsets but that doesn&#039;t take away from leveraging all the aspects of SOLID principles. 

Remember in TDD the steps are Red, Green, Refactor. Most people are really good at the Red, Green part of that equation but leave out the refactor aspect. 

One of the  reasons for people overlooking this is aspect is because it relies on experience and wisdom to guide you.  If you have never been introduced to a template or strategy pattern you will never know that you you need to refactor.  But if you have been trained and utilized these patterns you quickly see the opportunity to implement the pattern resulting in decreasing the technical debt through maintainability.  That is the beauty of patterns the a tried and true in decreasing complexity and increasing maintainability.

But like anything else these principle apply from a given context. As you mentioned the term &quot;Entity&quot; can be applied to any artifact of a software ecosystem.  At some point the artist must rely on experience and wisdom to guide their decisions.  I am not going to tell you that OCP will never be applicable at the assembly level but the probablity on its applicability is probably very small if not nil.

The principles are a result of good design pattern usage.  While the principle and patterns are mutually exclusive in their own right together they form a cohesive amalgam that leads to great software.



 

</description>
		<content:encoded><![CDATA[<p>@Christopher</p>
<p>>I know I&#8217;m being a little silly, but I do think that in certain cases the principles can (seem to) be fuzzy and conflicting. Especially for newcomers.</p>
<p>Well it depends&#8230;  The principles are meant to guide you in creating better software. Maintainability is only one aspect of great software.  TDD promotes DRY and YAGNI mindsets but that doesn&#8217;t take away from leveraging all the aspects of SOLID principles. </p>
<p>Remember in TDD the steps are Red, Green, Refactor. Most people are really good at the Red, Green part of that equation but leave out the refactor aspect. </p>
<p>One of the  reasons for people overlooking this is aspect is because it relies on experience and wisdom to guide you.  If you have never been introduced to a template or strategy pattern you will never know that you you need to refactor.  But if you have been trained and utilized these patterns you quickly see the opportunity to implement the pattern resulting in decreasing the technical debt through maintainability.  That is the beauty of patterns the a tried and true in decreasing complexity and increasing maintainability.</p>
<p>But like anything else these principle apply from a given context. As you mentioned the term &#8220;Entity&#8221; can be applied to any artifact of a software ecosystem.  At some point the artist must rely on experience and wisdom to guide their decisions.  I am not going to tell you that OCP will never be applicable at the assembly level but the probablity on its applicability is probably very small if not nil.</p>
<p>The principles are a result of good design pattern usage.  While the principle and patterns are mutually exclusive in their own right together they form a cohesive amalgam that leads to great software.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Christopher Bennage</title>
		<link>http://lostechies.com/joeocampo/2008/03/21/ptom-the-open-closed-principle/#comment-389</link>
		<dc:creator>Christopher Bennage</dc:creator>
		<pubDate>Wed, 26 Mar 2008 18:45:32 +0000</pubDate>
		<guid isPermaLink="false">/blogs/joe_ocampo/archive/2008/03/21/ptom-the-open-closed-principle.aspx#comment-389</guid>
		<description>Ok, I know this will be a bit much, but I just had a thought.  The quoted principle says OCP applies to &quot;software entities&quot;. The scope of an entity in this example is a class, but could it be a whole application? Adding specification classes is modifying the code of the application. Where do we draw the line?
As a TDD&#039;ers, we&#039;re inclined to do the simplest thing that works. If the client never mentioned size, then introducing specification might be YAGNI. Well, yeah, maybe...
I know I&#039;m being a little silly, but I do think that in certain cases the principles can (seem to) be fuzzy and conflicting. Especially for newcomers. I&#039;m always interested to know _why_ a given principle is useful.  The usual answer is because it promotes maintainability.</description>
		<content:encoded><![CDATA[<p>Ok, I know this will be a bit much, but I just had a thought.  The quoted principle says OCP applies to &#8220;software entities&#8221;. The scope of an entity in this example is a class, but could it be a whole application? Adding specification classes is modifying the code of the application. Where do we draw the line?<br />
As a TDD&#8217;ers, we&#8217;re inclined to do the simplest thing that works. If the client never mentioned size, then introducing specification might be YAGNI. Well, yeah, maybe&#8230;<br />
I know I&#8217;m being a little silly, but I do think that in certain cases the principles can (seem to) be fuzzy and conflicting. Especially for newcomers. I&#8217;m always interested to know _why_ a given principle is useful.  The usual answer is because it promotes maintainability.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Whatever</title>
		<link>http://lostechies.com/joeocampo/2008/03/21/ptom-the-open-closed-principle/#comment-388</link>
		<dc:creator>Whatever</dc:creator>
		<pubDate>Tue, 25 Mar 2008 12:15:24 +0000</pubDate>
		<guid isPermaLink="false">/blogs/joe_ocampo/archive/2008/03/21/ptom-the-open-closed-principle.aspx#comment-388</guid>
		<description>Great stuff. I&#039;m working hard to better understand OOD principles and work them in my code, and examples such as this help me to recognize when I&#039;m doing something stupid.

Keep up the great work.</description>
		<content:encoded><![CDATA[<p>Great stuff. I&#8217;m working hard to better understand OOD principles and work them in my code, and examples such as this help me to recognize when I&#8217;m doing something stupid.</p>
<p>Keep up the great work.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe Ocampo</title>
		<link>http://lostechies.com/joeocampo/2008/03/21/ptom-the-open-closed-principle/#comment-387</link>
		<dc:creator>Joe Ocampo</dc:creator>
		<pubDate>Sat, 22 Mar 2008 16:23:41 +0000</pubDate>
		<guid isPermaLink="false">/blogs/joe_ocampo/archive/2008/03/21/ptom-the-open-closed-principle.aspx#comment-387</guid>
		<description>You know after I posted I thought the same thing.  But I was hoping no one would call me on it!  Thanks Jeremy! :-)

But yes I agree I should follow this up with another post.</description>
		<content:encoded><![CDATA[<p>You know after I posted I thought the same thing.  But I was hoping no one would call me on it!  Thanks Jeremy! <img src='http://lostechies.com/joeocampo/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
<p>But yes I agree I should follow this up with another post.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeremy Gray</title>
		<link>http://lostechies.com/joeocampo/2008/03/21/ptom-the-open-closed-principle/#comment-386</link>
		<dc:creator>Jeremy Gray</dc:creator>
		<pubDate>Sat, 22 Mar 2008 15:45:25 +0000</pubDate>
		<guid isPermaLink="false">/blogs/joe_ocampo/archive/2008/03/21/ptom-the-open-closed-principle.aspx#comment-386</guid>
		<description>On the other hand, you violated separation of concern by mixing Specification with your filtering, and overconstrained the filter mechanism by accepting IList and returning IEnumerable (whereas you should have accepted IEnumerable), so perhaps another post in the series is in order? :)</description>
		<content:encoded><![CDATA[<p>On the other hand, you violated separation of concern by mixing Specification with your filtering, and overconstrained the filter mechanism by accepting IList and returning IEnumerable (whereas you should have accepted IEnumerable), so perhaps another post in the series is in order? <img src='http://lostechies.com/joeocampo/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
</channel>
</rss>
