Re: Information hiding?

On Thu, Feb 28, 2013 at 1:00 PM, Markus Lanthaler
<[email protected]>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