RE: Information hiding?

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