Loading ...
Sorry, an error occurred while loading the content.

Information hiding?

Expand Messages
  • Eric J. Bowman
    From REST, 5.2.1: allows information hiding through a generic interface I took a stab at a precise definition of information hiding but struck out. What
    Message 1 of 14 , Feb 27, 2013
    • 0 Attachment
      From REST, 5.2.1:

      "allows information hiding through a generic interface"

      I took a stab at a precise definition of "information hiding" but struck
      out. What information is hidden from whom? Anyone?

      -Eric
    • Markus Lanthaler
      ... The server s implementation details are hidden from the client. RPC, e.g., usually exposes all the methods exactly in the way they are implemented by the
      Message 2 of 14 , Feb 27, 2013
      • 0 Attachment
        > From REST, 5.2.1:
        >
        > "allows information hiding through a generic interface"
        >
        > I took a stab at a precise definition of "information hiding" but
        > struck
        > out. What information is hidden from whom? Anyone?

        The server's implementation details are hidden from the client. RPC, e.g.,
        usually exposes all the methods exactly in the way they are implemented by
        the server. This tightly couples the client to the server's internals. REST
        in contrast has a well defined interface so that the client doesn't (and
        doesn't have to) know anything about the server's internals.


        Cheers,
        Markus


        --
        Markus Lanthaler
        @markuslanthaler
      • Alan Dean
        Eric, Looking at the preceding two paragraphs for context, I would guess/think/say that the term information hiding refers to the hiding of the server
        Message 3 of 14 , Feb 27, 2013
        • 0 Attachment
          Eric,

          Looking at the preceding two paragraphs for context, I would guess/think/say that the term "information hiding" refers to the hiding of the server internal storage & retrieval mechanisms and formats by transforming the data into representations using 'generic' (syn. well-known) data formats and discoverable (via hypermedia) retrieval mechanisms.

          Regards,
          Alan Dean

          On Wed, Feb 27, 2013 at 9:52 PM, Eric J. Bowman <eric@...> wrote:
           

          From REST, 5.2.1:

          "allows information hiding through a generic interface"

          I took a stab at a precise definition of "information hiding" but struck
          out. What information is hidden from whom? Anyone?

          -Eric


        • Eric J. Bowman
          OK, Alan, Markus, that s what I came up with also. But then I second- guessed myself, because Roy also uses implementation details are opaque behind the
          Message 4 of 14 , Feb 27, 2013
          • 0 Attachment
            OK, Alan, Markus, that's what I came up with also. But then I second-
            guessed myself, because Roy also uses "implementation details are
            opaque behind the generic interface" and he doesn't usually mean
            precisely the same thing with two different terms, like "uniform" and
            "generic."

            -Eric
          • Alan Dean
            Eric, Hmmm ... not sure where you are referring to there. I can see * The resource implementation details are hidden behind the interface. * in [1] but that
            Message 5 of 14 , Feb 27, 2013
            • 0 Attachment
              Eric,

              Hmmm ... not sure where you are referring to there.

              I can see "The resource implementation details are hidden behind the interface." in [1] but that doesn't seem to be in conflict with "allows information hiding through a generic interface" to me.


              Alan

              On Wed, Feb 27, 2013 at 10:46 PM, Eric J. Bowman <eric@...> wrote:
              implementation details are
              opaque



              Regards,
              Alan Dean
            • Eric J. Bowman
              ... So information hiding is shorthand for implementation-detail hiding ? I guess I was thinking uses SQL is an implementation detail, while the results
              Message 6 of 14 , Feb 27, 2013
              • 0 Attachment
                Alan Dean wrote:
                >
                > I can see *"The resource implementation details are hidden behind the
                > interface."* in [1] but that doesn't seem to be in conflict with
                > *"allows information hiding through a generic interface"* to me.
                >

                So "information hiding" is shorthand for "implementation-detail hiding"?
                I guess I was thinking "uses SQL" is an implementation detail, while
                the results of a SQL query would be "information," and I was missing
                some subtlety.

                -Eric
              • Roy T. Fielding
                ... Information hiding is one of the first software engineering principles learned when systems became large enough to require modularity.
                Message 7 of 14 , Feb 28, 2013
                • 0 Attachment
                  On Feb 27, 2013, at 3:23 PM, Eric J. Bowman wrote:

                  > Alan Dean wrote:
                  >>
                  >> I can see *"The resource implementation details are hidden behind the
                  >> interface."* in [1] but that doesn't seem to be in conflict with
                  >> *"allows information hiding through a generic interface"* to me.
                  >>
                  >
                  > So "information hiding" is shorthand for "implementation-detail hiding"?
                  > I guess I was thinking "uses SQL" is an implementation detail, while
                  > the results of a SQL query would be "information," and I was missing
                  > some subtlety.

                  Information hiding is one of the first software engineering
                  principles learned when systems became large enough to require
                  modularity.

                  http://www.itmweb.com/essay550.htm

                  ....Roy
                • Nick Gall
                  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
                  Message 8 of 14 , Feb 28, 2013
                  • 0 Attachment
                    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.
                    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


                    On Thu, Feb 28, 2013 at 3:13 AM, Roy T. Fielding <fielding@...> wrote:
                    On Feb 27, 2013, at 3:23 PM, Eric J. Bowman wrote:

                    > Alan Dean wrote:
                    >>
                    >> I can see *"The resource implementation details are hidden behind the
                    >> interface."* in [1] but that doesn't seem to be in conflict with
                    >> *"allows information hiding through a generic interface"* to me.
                    >>
                    >
                    > So "information hiding" is shorthand for "implementation-detail hiding"?
                    > I guess I was thinking "uses SQL" is an implementation detail, while
                    > the results of a SQL query would be "information," and I was missing
                    > some subtlety.

                    Information hiding is one of the first software engineering
                    principles learned when systems became large enough to require
                    modularity.

                    http://www.itmweb.com/essay550.htm

                    ....Roy



                    ------------------------------------

                    Yahoo! Groups Links

                    <*> To visit your group on the web, go to:
                        http://groups.yahoo.com/group/rest-discuss/

                    <*> Your email settings:
                        Individual Email | Traditional

                    <*> To change settings online go to:
                        http://groups.yahoo.com/group/rest-discuss/join
                        (Yahoo! ID required)

                    <*> To change settings via email:
                        rest-discuss-digest@yahoogroups.com
                        rest-discuss-fullfeatured@yahoogroups.com

                    <*> To unsubscribe from this group, send an email to:
                        rest-discuss-unsubscribe@yahoogroups.com

                    <*> Your use of Yahoo! Groups is subject to:
                        http://docs.yahoo.com/info/terms/


                  • Eric J. Bowman
                    ... There s the subtlety I was missing; thanks, Roy. -Eric
                    Message 9 of 14 , Feb 28, 2013
                    • 0 Attachment
                      "Roy T. Fielding" wrote:
                      >
                      > Information hiding is one of the first software engineering
                      > principles learned when systems became large enough to require
                      > modularity.
                      >
                      > http://www.itmweb.com/essay550.htm
                      >

                      There's the subtlety I was missing; thanks, Roy.

                      -Eric
                    • Eric J. Bowman
                      ... My lack of formal training may be an advantage, because that s not how I did it. I m writing a modular httpd, where a NIO listener just makes
                      Message 10 of 14 , Feb 28, 2013
                      • 0 Attachment
                        Nick Gall wrote:
                        >
                        > But here we are 40 years later, still starting our designs by
                        > decomposing systems into steps in a process diagram.
                        >

                        My lack of formal training may be an advantage, because that's not how
                        I did it. I'm writing a modular httpd, where a NIO "listener" just
                        makes connections, and passes the socket's file descriptor off to a
                        vhost process; I define a vhost as one or more IP's / FQDN's which
                        share a configuration, the vhost is just a threaded cache incapable of
                        generating content.

                        Static files are served by a standalone FastCGI app, which maintains
                        multiplexed connections to those vhosts which use it. That's three
                        modules whose boundaries were determined by design decision -- the
                        listener is shaking out as procedural, vhost as OOP, file server as
                        functional, written in different languages.

                        >
                        > 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
                        >

                        Guess I'd better give that a read while I can still start over. Just
                        because I don't know what I'm doing, doesn't mean I can't learn! So
                        thanks for (unknowingly) pointing me the right direction. I wasn't even
                        going to mention my httpd project, except this is topical and timely to
                        what it is I'm doing.

                        -Eric
                      • Markus Lanthaler
                        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
                        Message 11 of 14 , Feb 28, 2013
                        • 0 Attachment

                          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: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] 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.

                          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

                        • Keith Hassen
                          Very interesting topic. :) This might just be a philosophical tangent, but ... I wonder if some of the lessons from evolutionary theory would be applicable ...
                          Message 12 of 14 , Feb 28, 2013
                          • 0 Attachment
                            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: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] 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.

                            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



                          • Nick Gall
                            On Thu, Feb 28, 2013 at 1:00 PM, Markus Lanthaler ... Parnas gave this general advice in his same paper: A data structure, its internal linkings, accessing
                            Message 13 of 14 , Feb 28, 2013
                            • 0 Attachment
                              On Thu, Feb 28, 2013 at 1:00 PM, Markus Lanthaler <markus.lanthaler@...> wrote:

                              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?


                              Parnas gave this general advice in his same paper: "A data structure, its internal linkings, accessing procedures and modifying procedures are part of a single module. They are not shared by many modules as is conventionally done. This notion is perhaps just an elaboration of the assumptions behind the papers of Balzer [9] and Mealy [10]. Design with this in mind is clearly behind the design of BLISS [11]."

                              What I like about this advice is it gets across that "module" as the unit of change according to Parnas does not mean a function, or a method, or a subroutine. A module means the entire set of dependencies that should change together. I think only aspect-oriented folk really get Parnas's sense of modularity.

                              Of course this begs the question of which parts of a data model, especially a shared one like a media type, "change together." I know of only a few general, cross-domain, principles regarding this issue. The rate of change of different parts of a data model are IME very domain-specific. That's why good data modeling is not a technical exercise, it is a business (or similar domain) exercise--only domain experts have a deep sense of the varying rates of change of the aspects of their domain.

                              That said, one of the few powerful general principles for factoring interfaces into "modules" whose components are more likely to change at the same rate comes from the AWWWv1: http://www.w3.org/TR/webarch/#orthogonal-specs . "Identification, interaction, and representation are orthogonal concepts, meaning that technologies used for identification, interaction, and representation may evolve independently." Or as I like to put it: IFaPs (Identifiers, Formats, & Protocols) should be as loosely coupled as possible because they are likely to change at different rates. Protocols change the slowest, identifiers next, and formats the most quickly.

                              "Architects can mature from being artists of space to become artists of time." — Stewart Brand

                              -- Nick

                            • Markus Lanthaler
                              ... Yeah.. that s one of the aspects that is still not 100% clear to me. (Most) media types not only define a serialization (representation) format but also
                              Message 14 of 14 , Mar 1, 2013
                              • 0 Attachment
                                On Thursday, February 28, 2013 8:56 PM, Nick Gall wrote:

                                > That said, one of the few powerful general principles for
                                > factoring interfaces into "modules" whose components are
                                > more likely to change at the same rate comes from the
                                > AWWWv1: http://www.w3.org/TR/webarch/#orthogonal-specs.
                                > "Identification, interaction, and representation are
                                > orthogonal concepts, meaning that technologies used for
                                > identification, interaction, and representation may evolve
                                > independently." Or as I like to put it: IFaPs (Identifiers,
                                > Formats, & Protocols) should be as loosely coupled as possible
                                > because they are likely to change at different rates. Protocols
                                > change the slowest, identifiers next, and formats the most quickly.

                                Yeah.. that's one of the aspects that is still not 100% clear to me. (Most)
                                media types not only define a serialization (representation) format but also
                                interaction models and sometimes specific semantic. Some are domain-specific
                                (to various degrees) while others are completely generic.

                                I tend more towards the use of completely domain-agnostic media types. Of
                                course, such media types need to provide some mechanism to express concrete
                                semantics (and thus hypermedia controls). The form doesn't really matter..
                                whether, e.g., XML-namespaces are used or a profile is associated with a
                                JSON file (preferably as media type parameter so that it's usable in conneg)
                                doesn't make a difference. I think this separation of concerns makes it much
                                easier to evolve systems in the long term since the parts may change at
                                different rates.

                                Maybe Roy could share his view on this as well.. I know he ran out of time
                                doing so a couple of years ago :-)


                                Thanks a lot,
                                Markus


                                --
                                Markus Lanthaler
                                @markuslanthaler
                              Your message has been successfully submitted and would be delivered to recipients shortly.