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

Re: [rest-discuss] Information hiding?

Expand Messages
  • 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 1 of 14 , Feb 28, 2013
      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 2 of 14 , Mar 1, 2013
        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.