Encapsulation theory

Hi, folks,

I posted an idea about encapsulation to this forum last October and received
some very helpful suggestions (mainly that the idea wasn't at all clear).

I've tried to clarify the point here:
http://www.edmundkirwan.com/pub/paper1.pdf

And, again, any comments would be appreciated.

The paper has little, I'm afraid, to offer the professional programmer, and
is aimed squarely at the student, new to the ideas of encapsulation and
information hiding.

Finally to our good mister Perryman, I humbly apologise: you asked two
questions last December which I left unanswered.

The questions were:

1. Do I think that this a means of quantitatively evaluating encapsulation?
Ans: yes, though not the only one; I'm sure there are countless other,
doubtless far more important means.

2. Do I think (1) can be captured in a metric? Ans: no, not a single metric,
but the configuration efficiency is perhaps not valueless.

Thanks for your time,

Ed Kirwan

--

www.EdmundKirwan.com - Home of encapsulation theory.

Ed Kirwan wrote:

> Finally to our good mister Perryman, I humbly apologise: you asked two
> questions last December which I left unanswered.

> The questions were:

> 1. Do I think that this a means of quantitatively evaluating encapsulation?
> Ans: yes, though not the only one; I'm sure there are countless other,
> doubtless far more important means.

> 2. Do I think (1) can be captured in a metric? Ans: no, not a single metric,
> but the configuration efficiency is perhaps not valueless.

<quote>

My understanding is that you believe that you :

1. have a theory regarding macro-level encapsulations (name-spaces,
packages etc) that qualitatively/quantitatively evaluates an
encapsulation E in terms of the dependency/coupling between E and its
peers.

2. can define metrics for bounding where/when E is a good/acceptable
encapsulation (in terms of 1) , and when E has/will become
progressively worse.

Is the above close to what you believe you are presenting to us ??
If not, feel free to tell us what you are attempting to do with your stuff.

<quote>

So my query still stands ...


Regards,
Steven Perryman

S Perryman wrote:

> Ed Kirwan wrote:
>

Snip.
> <quote>
>
> My understanding is that you believe that you :
>
> 1. have a theory regarding macro-level encapsulations (name-spaces,
> packages etc) that qualitatively/quantitatively evaluates an
> encapsulation E in terms of the dependency/coupling between E and its
> peers.
>
> 2. can define metrics for bounding where/when E is a good/acceptable
> encapsulation (in terms of 1) , and when E has/will become
> progressively worse.
>
> Is the above close to what you believe you are presenting to us ??
> If not, feel free to tell us what you are attempting to do with your
> stuff.
>
> <quote>
>
> So my query still stands ...

Thanks for the reply, mister Perryman.

I can't give a categorical, "Yes," to either answer, so I will take your,
"Feel free to tell us ..." option.

What I attempted to do is to show that the maximum connectedness of a
collection of source code programs is dependent on encapsulation and
information hiding.

Take a system of three Java classes: A, B and C. A and B reside in package
one and C resides in package two. All classes are public.

Consider that A depends on B and B depends on C.

Thus there are 2 dependencies.

But what is the maximum number of possible source code dependencies? The
answer is 6: each class can depend on two others.

Now consider that A is made package-private (default accessor) inside
package one (in other words, it is information-hidden inside package one).

Now what is the maximum number of possible source code dependencies? The
answer is 5 (C now cannot form a dependency towards A).

Thus, the maximum connectedness of a collection of source code programs is
dependent on encapsulation and information hiding.

If that's blazingly obvious then the paper really has little to offer, hence
the paper's being directed at students.

Ed Kirwan.

--

www.EdmundKirwan.com - Home of encapsulation theory.

Ed Kirwan wrote:

> I can't give a categorical, "Yes," to either answer, so I will take your,
> "Feel free to tell us ..." option.

> What I attempted to do is to show that the maximum connectedness of a
> collection of source code programs is dependent on encapsulation and
> information hiding.

> Take a system of three Java classes: A, B and C. A and B reside in package
> one and C resides in package two. All classes are public.

> Consider that A depends on B and B depends on C.

> Thus there are 2 dependencies.

> But what is the maximum number of possible source code dependencies? The
> answer is 6: each class can depend on two others.

If you consider a system to be a directed graph, then the number of edges
(the dependencies) is by definition (for N components) : N * (N + 1) / 2

However, we are dealing with software. In particular programming languages.


> Now consider that A is made package-private (default accessor) inside
> package one (in other words, it is information-hidden inside package one).

> Now what is the maximum number of possible source code dependencies? The
> answer is 5 (C now cannot form a dependency towards A).

> Thus, the maximum connectedness of a collection of source code programs is
> dependent on encapsulation and information hiding.

Prog languages have invariant properties regarding formation of the graph
(dependency cycles, mutually recursive definitions etc) . So the set of
graphs for a given prog lang and component set, will be a subset of those
feasible for a general digraph with N nodes.

IOW, the upper bounds on connectivity is determined by the *rules* of
encapsulation etc.

So you get ...

FORALL Lang L, Components C : dependencies(L,C) <= SumToN(C.elements)

From here you have to refine the dependencies function.
This means building dependency classifications based on the various
dependency/encapsulation schemes widely used in prog langs (scheme1(C) ,
scheme2(C) etc) .

Then for a particular prog lang, and a set of components, you can
more precisely define the dependencies function :

dependencies(Ada,C) = some expression based on scheme1, scheme3 etc.
dependencies(Java,C) = some expression based on scheme1, schemeX etc.


Regards,
Steven Perryman

Ed Kirwan wrote:

> The paper has little, I'm afraid, to offer the professional programmer, and
> is aimed squarely at the student, new to the ideas of encapsulation and
> information hiding.

I didn't have the time to read through the paper,
but I applaud the effort to tackle this important
concept in software-engineering.

We are all students over our careers as sw engineers,
or even computer scientists perhaps. The concept of
"encapsulation" is hard to define precisely, so I
applaud every effort to analyze it.

Further, mathematical formulas are great, but they
are not enough to understand a phenomenon completely.
We also need conceptual explanations, perhaps also
visualizations to give us us a grasp on the "essence"
of anything, as opposed to merely "computing" a set
of metrics. The answer may be 42, but what is the
significance of it being 42?

Can you come up perhaps with a one paragraph extract
of your paper that could provide its essence to students,
professionals, and even scholars?

Thanks
-Panu Viljamaa

On 30 Juli, 11:47, S Perryman <q...@q.net> wrote:
> Ed Kirwan wrote:
> > I can't give a categorical, "Yes," to either answer, so I will take your,
> > "Feel free to tell us ..." option.
> > What I attempted to do is to show that the maximum connectedness of a
> > collection of source code programs is dependent on encapsulation and
> > information hiding.
> > Take a system of three Java classes: A, B and C. A and B reside in package
> > one and C resides in package two. All classes are public.
> > Consider that A depends on B and B depends on C.
> > Thus there are 2 dependencies.
> > But what is the maximum number of possible source code dependencies? The
> > answer is 6: each class can depend on two others.
>
> If you consider a system to be a directed graph, then the number of edges
> (the dependencies) is by definition (for N components) : N * (N + 1) / 2

(Isn't that factor 2 only valid for non-directed graphs?)

>
> However, we are dealing with software. In particular programming languages.

Indeed, though I'd hope that there is some useful information we can
take from digraphs and apply it to software to the degree to which the
software can be represented as a digraph.

>
> > Now consider that A is made package-private (default accessor) inside
> > package one (in other words, it is information-hidden inside package one).
> > Now what is the maximum number of possible source code dependencies? The
> > answer is 5 (C now cannot form a dependency towards A).
> > Thus, the maximum connectedness of a collection of source code programs is
> > dependent on encapsulation and information hiding.
>
> Prog languages have invariant properties regarding formation of the graph
> (dependency cycles, mutually recursive definitions etc) . So the set of
> graphs for a given prog lang and component set, will be a subset of those
> feasible for a general digraph with N nodes.
>
> IOW, the upper bounds on connectivity is determined by the *rules* of
> encapsulation etc.

I entirely agree. The paper distinguishes between two types of
information hiding:

i) Absolute information hiding, in which a program unit's
accessibility is defined only by that program unit and is not
dependent on that program unit's relation to the rest of the system.

ii) Relative information hiding, in which a program unit's possible
accessibility depends on its relation to the rest of the system.

I consider (i) to be an ideal case, the case of an ideal software
language. Java approximates this in that a class declared as public is
visible to all other classes in the system. It is this type of ideal
system that is considered in the paper.

I consider (ii) to be what you describe, and even more so, as there
are extra-linguistic rules that may be applied even to different
programs written in the same langauge. As these rules are limitless,
the paper only gives an example of two (layering and a two-dimensional
hierarchical encapsulation context) and only to show that such systems
can reduce connectivity below that achievable by the ideal case.

>
> So you get ...
>
> FORALL Lang L, Components C : dependencies(L,C) <= SumToN(C.elements)
>
> From here you have to refine the dependencies function.
> This means building dependency classifications based on the various
> dependency/encapsulation schemes widely used in prog langs (scheme1(C) ,
> scheme2(C) etc) .
>
> Then for a particular prog lang, and a set of components, you can
> more precisely define the dependencies function :
>
> dependencies(Ada,C) = some expression based on scheme1, scheme3 etc.
> dependencies(Java,C) = some expression based on scheme1, schemeX etc.

This dependency function for Java, then, is what the paper tries to
deliver (or a close approximation thereof).

It's may be interesting to note that the order of the maximum
connectivity that you gave in your equation above is 2, and the order
of the dependency function for Java is 1.5. Thus for a system of a 100
Java classes, the maximum connectivity is around 10,000 but the
minimum possible achieved by fully optimised encapsulation is 1800.

Thus, adding that 101st class to an unencapsulated system gives you
fives times more possible ways to inch the system closer to a Big Ball
Of Mud than adding that same class to an optimally encapsulated
system.

>
> Regards,
> Steven Perryman

Ed

--

www.EdmundKirwan.com - Home of encapsulation theory.

"Ed" <iamfractal@hotmail.com> wrote in message
news:28fc3a80-682e-44b2-92b4-8bf0388b2523@m36g2000hse.googlegroups.com...

> On 30 Juli, 11:47, S Perryman <q...@q.net> wrote:

>> If you consider a system to be a directed graph, then the number of edges
>> (the dependencies) is by definition (for N components) : N * (N + 1) / 2

> (Isn't that factor 2 only valid for non-directed graphs?)

Correct (mathematically) .

In a real prog lang, I doubt that the worst case is possible (the worse case
allowed is probably a cycle) , but without a suitable prog lang to hand to
test
with, I cannot say for certain.


>> However, we are dealing with software. In particular programming
>> languages.

> Indeed, though I'd hope that there is some useful information we can
> take from digraphs and apply it to software to the degree to which the
> software can be represented as a digraph.

Software dependency is well represented as a graph.


>> Prog languages have invariant properties regarding formation of the graph
>> (dependency cycles, mutually recursive definitions etc) . So the set of
>> graphs for a given prog lang and component set, will be a subset of those
>> feasible for a general digraph with N nodes.

>> IOW, the upper bounds on connectivity is determined by the *rules* of
>> encapsulation etc.

> I entirely agree. The paper distinguishes between two types of
> information hiding:

> i) Absolute information hiding, in which a program unit's
> accessibility is defined only by that program unit and is not
> dependent on that program unit's relation to the rest of the system.

> ii) Relative information hiding, in which a program unit's possible
> accessibility depends on its relation to the rest of the system.

The canonical definition of information hiding is that implementation
detail relating to a component is not visible to users of the
component. Good examples are Ada, CLU, Modula-2.

The other extreme is where implementation detail is visible, and
its definition (or changes therein) impact the user. C++ being a
good example.

Within that spectrum, there are variations on the theme (Java
and protected/private at the package level etc) .

For any discussion of any given prog lang P, you should be
able to enumerate all the dependency relations that can exist
between components in P.

What do you think the set of relationships are for Java ??


Regards,
Steven Perryman

Panu wrote:

> Ed Kirwan wrote:
>
>> The paper has little, I'm afraid, to offer the professional programmer,
>> and is aimed squarely at the student, new to the ideas of encapsulation
>> and information hiding.
>
> I didn't have the time to read through the paper,
> but I applaud the effort to tackle this important
> concept in software-engineering.
>
> We are all students over our careers as sw engineers,
> or even computer scientists perhaps. The concept of
> "encapsulation" is hard to define precisely, so I
> applaud every effort to analyze it.
>
> Further, mathematical formulas are great, but they
> are not enough to understand a phenomenon completely.
> We also need conceptual explanations, perhaps also
> visualizations to give us us a grasp on the "essence"
> of anything, as opposed to merely "computing" a set
> of metrics. The answer may be 42, but what is the
> significance of it being 42?
>
> Can you come up perhaps with a one paragraph extract
> of your paper that could provide its essence to students,
> professionals, and even scholars?

Hi, Panu, thanks for the reply.

A one-paragraph extract would probably look remarkably like this:

"There exists a relationship between the maximum possible number of source
code dependencies between program units of a software system, and the
encapsulation and information hiding strategies employed in that system.
Furthermore, this maximum possible number of source code dependencies may
be minimised by an optimal choice of encapsulation and information hiding
strategy."

(Many stumble over that minimising-of-a-maximum concept; most get up, brush
themselves off and scarper out the nearest door. Alas, this
minimising-of-a-maximum concept is central to the paper.)

In practice, this, "Encapsulation and information hiding strategy," reduces
to two, well-known pieces of advice:

i) Restrict program unit access as much as possible. In Java, for instance,
this means that no class should be declared as public unless it's used
outside its subsystem.

ii) Avoid abnormally large subsystems. If a system contains just two
subsystems, one with 100 program units and one with 10 program units, then
the larger subsystem should be broken down into several, smaller
subsystems.

So the paper, sadly, offers no new, galaxy-shattering advances for software
engineering; it merely provides a fluttering scrap of mathematical support
for extant best practice. Furthermore, the paper doesn't attempt to cover
all encapsulation contexts (see my response to Mister Perryman earlier
today), it's just a sliver of light cast over a simple case.

Do, please, let me know if the extract above is at all clear. There are
three other significant points that the paper attempts to convery: I'd be
delighted to attempt to summarise those, too, if you like.

>
> Thanks
> -Panu Viljamaa

Regards,

Ed.
--
Encapsulation theory fundamentals:
www.EdmundKirwan.com/pub/paper1.pdf

S Perryman wrote:

>
> The canonical definition of information hiding is that implementation
> detail relating to a component is not visible to users of the
> component. Good examples are Ada, CLU, Modula-2.
>
> The other extreme is where implementation detail is visible, and
> its definition (or changes therein) impact the user. C++ being a
> good example.
>
> Within that spectrum, there are variations on the theme (Java
> and protected/private at the package level etc) .

You raise another excellent point, of course: definitions.

The paper provides a definition of information hiding as, "The restricting
of forming dependencies on any particular program unit within a subsystem
from outside that subsystem."

This is not the canonical definition that you quote above but a definition
is only as good as the utility to which it gives rise.

>
> For any discussion of any given prog lang P, you should be
> able to enumerate all the dependency relations that can exist
> between components in P.
>
> What do you think the set of relationships are for Java ??

Well, the paper doesn't give the set of relationships for Java but the
maximum number of source code dependencies and shows how this minimised for
a certain number of packages each with a certain number of public classes.

And it won't give this figure for Java at all, but for a simplified language
that is a close approximation of Java: that approximation being a Java
without the, "Protected," keyword. When analysing Java, then, this
approximation presumes that most classes are not protected; you can judge
for yourself the validity of that argument. Let me know if that rather
thick slice of approximation is too much to swallow and whether it's worth
discussing the idealised, simplified language instead.

>
>
> Regards,
> Steven Perryman

Regards,

Ed.

--
Encapsulation theory fundamentals:
www.EdmundKirwan.com/pub/paper1.pdf

"Ed Kirwan" <IAmFractal@hotmail.com> wrote in message
news:g89um1$he0$1@aioe.org...

>S Perryman wrote:

>> The canonical definition of information hiding is that implementation
>> detail relating to a component is not visible to users of the
>> component. Good examples are Ada, CLU, Modula-2.

>> The other extreme is where implementation detail is visible, and
>> its definition (or changes therein) impact the user. C++ being a
>> good example.

>> Within that spectrum, there are variations on the theme (Java
>> and protected/private at the package level etc) .

> You raise another excellent point, of course: definitions.

It is not sensible to redefine long-standing terms within a given subject
domain. It only confuses people. And within the CS domain, the OO
community have been very loose on this matter (a classic being equating
encapsulation with information hiding) .


> The paper provides a definition of information hiding as, "The restricting
> of forming dependencies on any particular program unit within a subsystem
> from outside that subsystem."

But you have to precisely define what dependency actually is.
For any given component C, there can be dependency on Cs' :

- interface
- implementation
- transitive closure (all the components that C depends on - directly or
indirectly)
- release granularity (the package etc to which C belongs to)
- etc


>> For any discussion of any given prog lang P, you should be
>> able to enumerate all the dependency relations that can exist
>> between components in P.

>> What do you think the set of relationships are for Java ??

> Well, the paper doesn't give the set of relationships for Java but the
> maximum number of source code dependencies and shows how this minimised
> for
> a certain number of packages each with a certain number of public classes.

The minimal structure possible for any graph is a tree.
So for a dependency graph, the number of dependencies for a tree = N - 1.
The dependency bounds (D) for any directed graph is by definition :

(D(N) = 0) = (N = 1)
(N > 1) AND ( D(N) / (N - 1) IN [1,N] )

What definition of dependency you use, a system of components will produce
a value in those bounds. For example, the optimal encapsulation for release
granularity would be one that recursively defines encapsulations as trees.


Regards,
Steven Perryman