<?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"
	>
<channel>
	<title>Comments on: Why Hide Information?</title>
	<atom:link href="http://blogs.teamb.com/craigstuntz/2007/10/26/37763/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.teamb.com/craigstuntz/2007/10/26/37763/</link>
	<description>C# • Entity Framework • Functional Programming • MVC • Web</description>
	<pubDate>Sun, 12 Feb 2012 05:05:11 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: Dan Bernier</title>
		<link>http://blogs.teamb.com/craigstuntz/2007/10/26/37763/#comment-958</link>
		<dc:creator>Dan Bernier</dc:creator>
		<pubDate>Wed, 31 Oct 2007 19:55:53 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.teamb.com/craigstuntz/2007/10/26/37763#comment-958</guid>
		<description>I meant something else, actually...that information hiding, by making state inaccessible to clients, shrinks the amount the programmer has to consider.

It's like a corollary to point 3:  clients can't touch the state, so the designer can ignore both the client's impact on state, and variables in the client's space.

While information hiding makes the thing easier to use from the outside, it also makes it easier to change from the inside.</description>
		<content:encoded><![CDATA[<p>I meant something else, actually&#8230;that information hiding, by making state inaccessible to clients, shrinks the amount the programmer has to consider.</p>
<p>It&#8217;s like a corollary to point 3:  clients can&#8217;t touch the state, so the designer can ignore both the client&#8217;s impact on state, and variables in the client&#8217;s space.</p>
<p>While information hiding makes the thing easier to use from the outside, it also makes it easier to change from the inside.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Craig Stuntz</title>
		<link>http://blogs.teamb.com/craigstuntz/2007/10/26/37763/#comment-914</link>
		<dc:creator>Craig Stuntz</dc:creator>
		<pubDate>Mon, 29 Oct 2007 13:07:56 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.teamb.com/craigstuntz/2007/10/26/37763#comment-914</guid>
		<description>Greg: Yes, exactly.

Dan: Yes, this is essentially point 1 in my post, expressed a bit differently.</description>
		<content:encoded><![CDATA[<p>Greg: Yes, exactly.</p>
<p>Dan: Yes, this is essentially point 1 in my post, expressed a bit differently.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Bernier</title>
		<link>http://blogs.teamb.com/craigstuntz/2007/10/26/37763/#comment-913</link>
		<dc:creator>Dan Bernier</dc:creator>
		<pubDate>Mon, 29 Oct 2007 12:08:38 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.teamb.com/craigstuntz/2007/10/26/37763#comment-913</guid>
		<description>3x + y = 9 + y
- subtract out y
3x = 9

Isn't information hiding partly about reducing the number of things to consider?  I've heard David Ungar quoted as saying, "Interfaces are about psychological chunking."</description>
		<content:encoded><![CDATA[<p>3x + y = 9 + y<br />
- subtract out y<br />
3x = 9</p>
<p>Isn&#8217;t information hiding partly about reducing the number of things to consider?  I&#8217;ve heard David Ungar quoted as saying, "Interfaces are about psychological chunking."</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Greg M</title>
		<link>http://blogs.teamb.com/craigstuntz/2007/10/26/37763/#comment-909</link>
		<dc:creator>Greg M</dc:creator>
		<pubDate>Mon, 29 Oct 2007 02:20:15 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.teamb.com/craigstuntz/2007/10/26/37763#comment-909</guid>
		<description>State (if there is any) is part of the interface, but a part that tends to be poorly documented. Most languages don't have support for annotating state-change in the type-system, so it's hard to rigorously specify. Functional programmers have known for years that eliminating unnecessary state reduces coupling and leads to clean and robust modularity.</description>
		<content:encoded><![CDATA[<p>State (if there is any) is part of the interface, but a part that tends to be poorly documented. Most languages don&#8217;t have support for annotating state-change in the type-system, so it&#8217;s hard to rigorously specify. Functional programmers have known for years that eliminating unnecessary state reduces coupling and leads to clean and robust modularity.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Abhijit Nadgouda</title>
		<link>http://blogs.teamb.com/craigstuntz/2007/10/26/37763/#comment-901</link>
		<dc:creator>Abhijit Nadgouda</dc:creator>
		<pubDate>Sun, 28 Oct 2007 05:53:01 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.teamb.com/craigstuntz/2007/10/26/37763#comment-901</guid>
		<description>I think one of the other problems of hiding information is hiding too much of it, and creating wrong ownerships. It is important to identify which information hide, or to hide the information that is unnecessary to others.</description>
		<content:encoded><![CDATA[<p>I think one of the other problems of hiding information is hiding too much of it, and creating wrong ownerships. It is important to identify which information hide, or to hide the information that is unnecessary to others.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

