Re: Information hiding?

Very interesting topic. :)

This might just be a philosophical tangent, but ... I wonder if some of the lessons from evolutionary theory would be applicable ... systems that can interact successfully (APIs? agents of the web?), produce offspring (e.g. web systems that learn from each other and produce new, more flexible systems), with the occasional mutation (experimentation by design).  You may start in a very dark place but provided you define the right fitness goals (the measure of success), it could be that the answer to these kinds of questions are necessarily hidden from us and are best solved by encouraging interaction and growth. :)

K


On 2013-02-28, at 1:00 PM, Markus Lanthaler wrote:

> 
> Thanks for the great pointer Nick.
> 
>  
> 
> While hiding “functionality” isn’t really surprising giving REST’s uniform interface it is much less apparent when looking at the data model - at least for me.
> 
>  
> 
> Sure, you can decouple your internal data model from your external one by creating (and standardizing) a media type. But what are guidelines to create such a type? Which data do you expose and which do you hide? What if you decide to remove some data in the future or it is just not reasonable anymore to expose it?
> 
>  
> 
>  
> 
> Cheers,
> 
> Markus
> 
>  
> 
>  
> 
> --
> 
> Markus Lanthaler
> 
> @markuslanthaler
> 
>  
> 
>  
> 
>  
> 
> From: [email protected] [mailto:[email protected]] On Behalf Of Nick Gall
> Sent: Thursday, February 28, 2013 4:01 PM
> To: Rest List
> Subject: Re: [rest-discuss] Information hiding?
> 
>  
> 
> My favorite expression of information hiding is this passage from the closing section of David Parnas's seminal essay, "On the Criteria To Be Used in Decomposing Systems into Modules": "...it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.
> 
> http://en.wikipedia.org/wiki/David_Parnas#Quotations
> 
> Parnas D.L. (December 1972). "On the Criteria To Be Used in Decomposing Systems into Modules". Comm ACM 15 (12): 1053–8. doi:10.1145/361598.361623
> 
>  
> 
> In other words, information hiding is the hiding of design decisions--especially those design decisions likely to change. Information hiding is NOT just about hiding implementation details; it is much more about hiding (an at least indirecting--a form of hiding) design issues. But here we are 40 years later, still starting our designs by decomposing systems into steps in a process diagram.
> 
>  
> 
> -- Nick
> 
> 
> 
> Nick Gall
> Phone: +1.781.608.5871
> Other Contact Info: http://bit.ly/nickgall
> 
> 
>