<?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: Building a Versatile Application</title>
	<atom:link href="http://darylteo.com/blog/2007/01/28/building-a-versatile-application/feed/" rel="self" type="application/rss+xml" />
	<link>http://darylteo.com/blog/2007/01/28/building-a-versatile-application/</link>
	<description>Bits and blobs on anything tech</description>
	<lastBuildDate>Sat, 31 Dec 2011 19:51:45 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Mims H Wright</title>
		<link>http://darylteo.com/blog/2007/01/28/building-a-versatile-application/comment-page-1/#comment-25</link>
		<dc:creator>Mims H Wright</dc:creator>
		<pubDate>Mon, 26 Feb 2007 15:35:51 +0000</pubDate>
		<guid isPermaLink="false">http://darylteo.com/blog/2007/01/28/building-a-versatile-application/#comment-25</guid>
		<description>I sometimes suffer from compulsive versatility. I once tried to create a 3d package and wound up spending about 2 weeks just adding vector math that I never even needed. It can be very satisfying to have a completely spec&#039;d out class with everything working but for the most part it&#039;s a bad habit to have.
The only times when you really need to fully build out a class or package in my opinion is when you&#039;re building a  library or something else that will be frequently reused by other coders. Even then it&#039;s important to stick to your core functionality and not start building in unnecessary elements. Error handling and validation might be an exception if it&#039;s prone to failure.
A technique that might help your design is to think of everything from an interface-oriented perspective. Design your program with the interface in mind which may help you focus on the functionality that you need to make your program work rather than the robustness of your classes. In this case, all you need is ISoundGenerator. You can deal with IDomesticatable, IMultiLeggedCreature, ICreatureWithSize, and IColored when you get to them.</description>
		<content:encoded><![CDATA[<p>I sometimes suffer from compulsive versatility. I once tried to create a 3d package and wound up spending about 2 weeks just adding vector math that I never even needed. It can be very satisfying to have a completely spec&#8217;d out class with everything working but for the most part it&#8217;s a bad habit to have.<br />
The only times when you really need to fully build out a class or package in my opinion is when you&#8217;re building a  library or something else that will be frequently reused by other coders. Even then it&#8217;s important to stick to your core functionality and not start building in unnecessary elements. Error handling and validation might be an exception if it&#8217;s prone to failure.<br />
A technique that might help your design is to think of everything from an interface-oriented perspective. Design your program with the interface in mind which may help you focus on the functionality that you need to make your program work rather than the robustness of your classes. In this case, all you need is ISoundGenerator. You can deal with IDomesticatable, IMultiLeggedCreature, ICreatureWithSize, and IColored when you get to them.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

