Encapsulation theory : Object

(Forgive me if this post appears twice.)

> "Ed Kirwan" <IAmFrac...@hotmail.com> wrote in message
(Snip.)
>
> > i) Minimise scope. This best practice advises that, for example, if a
> > program unit within a subsystem is only used by other program units
within
> > the subsystem, then it should usually not be accessible outside that
> > subsystem.
>
>S Perryman wrote:
>
> Not so, because the above conflicts with *utility* .
> The fact that a component is *currently* used only within one unit
> of encapsulation does not mean it should be confined to that unit.


This statement was of great interest to me. I had thought that a programmer
would always minimise the scope of a method within a program unit and a
program unit within a subsystem.

So I took a look at some of the Java systems on sourceforge and it looks
like
I was wrong: there seem to be a surprising number of systems with a low
configuration efficiency, i.e., large numbers of public classes (even when
no classes outside those packages call those public classes) and wide
variation in package size:

http://www.edmundkirwan.com/encap/survey1/index.html


>
> And this is where your problem with information hiding comes.
> The concept in effect :
>
> 1. removes dependency on implementation decisions
> 2. (implicitly) protects from component users violating the state of said
> implementations (you cannot access what you cannot see) .
>
> So 2 becomes a much stronger criteria for determining access to such
> components. And 1 is prog-lang dependent (again going back
> to my statement that you must define the particular prog lang and
dependency
> relations) .
>
> > ii) Optimise size. This best practice says that if our system consists
of
> > two subsystems and one subsystem has ten times as many program units as
> > the
> > other, then the larger subsystem should usually be decomposed into
> > several,
> > smaller subsystems.
>
> To manage complexity (understanding specifically - which is a human
issue) .
>
> > Neither is provable - to my limited knowledge - for any cases given the
> > current, canonical definitions.
>
> Is it not provable that :
>
> - uncontrolled access to components +/- their properties can result in s/w
> that
> has compromised its own correctness.
>
> - depending on the prog lang, dependency (direct or transitive) on
> components
> that are not referenced by a user UC nor the component itself, has
> quantifiable
> measures for the extent to which system change will affect UC.
>

Agreed, I know of no such proofs either.


>
>
> > Given the re-wording of information hiding from the earlier post, and
the
> > re-wording ofencapsulationas, "The placing of program units within a
> > subsystem," then for a simplified, idealised programming language, both
> > best
> > practices can be proved in terms of the maximum possible number of
source
> > code dependencies of a system. (These wordings are the lay translations
of
> > the actual mathematical definitions used in the proofs.)
> > As you noted already, the maximum possible number of source code
> > dependencies, s, for an unencapsulated system is of n program units is
> > given by:
> > s = n(n-1)
> > Using the definitions above, we can show that the lowest figure for this
> > maximum possible number of source code dependencies where p is the
number
> > of
> > program units accessible outside an individual subsystem is given by:
> > s = n(2 * sqrt(np) -1 -p)
>
> The lowest number of possible component dependencies = N - 1.
> As I stated, this is when the dependency graph is a tree.

True, with relative information hiding, you can construct such a system. For
example, take four Java classes A, B, C and D. If you put each class in a
separate package, have one class per package public and invoke the design
rule
such as, "A package may only depend on the next lower package," (where the
packages are arranged as layers in a stack) then you'd get:

A -> B -> C -> D

With precisely the three dependencies you mention.

For absolute information hiding, such as Java without that design rule, then
B
can possibly depend back on A, and on D; all the others can possibly depend
on
one another, also.

In this case, with one public class per package, the number of packages that
minimises the maximum possible dependcies is 2, and the minimum number of
possible dependencies s = 4(2 * sqrt(4 * 1) -1 -1) = 8.

Though all that is unimportant if the survey of sourceforge is indicative of
widespread practice: namely that programmers are content with low
configuration efficiencies, leaving a substantial proportion of their
classes
public even when nothing outside the hosting package depends on them.

Regards,

Ed.

--
www.EdmundKirwan.com - Home of encapsulation theory