<?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: Chapter 5 &#8211; Taming the Beast</title>
	<atom:link href="http://www.kirkk.com/modularity/2009/12/chapter-5-taming-the-beast/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.kirkk.com/modularity/2009/12/chapter-5-taming-the-beast/</link>
	<description>Patterns of Modular Architecture</description>
	<lastBuildDate>Wed, 01 Sep 2010 02:37:32 -0600</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Kirk Knoernschild</title>
		<link>http://www.kirkk.com/modularity/2009/12/chapter-5-taming-the-beast/comment-page-1/#comment-39</link>
		<dc:creator>Kirk Knoernschild</dc:creator>
		<pubDate>Wed, 01 Sep 2010 02:37:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.kirkk.com/modularity/?p=82#comment-39</guid>
		<description>I understand the dilemma you describe, and it&#039;s largely a product of system size. Look at the diagram in Chapter 2 that illustrates the differentiating factors surrounding classes, packages, modules, and services.

Certainly it&#039;s possible to fathom a system that is so complex that there might be such a large quantity of modules that it&#039;s still difficult to understand. But now take modularity out of the picture for that same system and it&#039;s virtually impossible to understand. Then imagine leveraging the four units of composition illustrated in the diagram in Chapter 2, and you can at least imagine a non-trivial software system that is manageable.</description>
		<content:encoded><![CDATA[<p>I understand the dilemma you describe, and it&#8217;s largely a product of system size. Look at the diagram in Chapter 2 that illustrates the differentiating factors surrounding classes, packages, modules, and services.</p>
<p>Certainly it&#8217;s possible to fathom a system that is so complex that there might be such a large quantity of modules that it&#8217;s still difficult to understand. But now take modularity out of the picture for that same system and it&#8217;s virtually impossible to understand. Then imagine leveraging the four units of composition illustrated in the diagram in Chapter 2, and you can at least imagine a non-trivial software system that is manageable.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stefan Panayotov</title>
		<link>http://www.kirkk.com/modularity/2009/12/chapter-5-taming-the-beast/comment-page-1/#comment-38</link>
		<dc:creator>Stefan Panayotov</dc:creator>
		<pubDate>Tue, 31 Aug 2010 20:26:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.kirkk.com/modularity/?p=82#comment-38</guid>
		<description>Let me first say that I agree with everything said up to here. But one thing starts worring me. The levels of abstraction. You are saying that OO did not deliver on the promises to make systems more managable and reusable, because objects are too fine-grained. Modularity will deliver on these promises, because modules are coarse-grained and developers will understand the systems better by focusing on a single module at a time. My burning question is: if we extrapolate this what will happen - developers will start creating more complex systems with more modules and eventually we&#039;ll end up with a mess of thousasnds of modules (look at the top lect picture above and assume each small rectangle there is a module instead of class). So, now we have to introduce another level of abstraction to encapsulate modules into some even coarser grained component that will help us understand and manage the system. Something like the &quot;Man in Black&quot; movie where in the end it shows our whole universe being like a marble ball in the hands of some extraterestrials that are playing with it. What do you think about this?</description>
		<content:encoded><![CDATA[<p>Let me first say that I agree with everything said up to here. But one thing starts worring me. The levels of abstraction. You are saying that OO did not deliver on the promises to make systems more managable and reusable, because objects are too fine-grained. Modularity will deliver on these promises, because modules are coarse-grained and developers will understand the systems better by focusing on a single module at a time. My burning question is: if we extrapolate this what will happen &#8211; developers will start creating more complex systems with more modules and eventually we&#8217;ll end up with a mess of thousasnds of modules (look at the top lect picture above and assume each small rectangle there is a module instead of class). So, now we have to introduce another level of abstraction to encapsulate modules into some even coarser grained component that will help us understand and manage the system. Something like the &#8220;Man in Black&#8221; movie where in the end it shows our whole universe being like a marble ball in the hands of some extraterestrials that are playing with it. What do you think about this?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
