Ed Kirwan
Guest
|
 Posted: Thu Nov 06, 2008 12:03 am Post subject: Encapsulation theory |
 |
|
(Forgive me if this post appears twice.)
| Quote: | "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
| Quote: |
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.
| Quote: |
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 |
|
S Perryman
Guest
|
| Posted: Tue Nov 18, 2008 9:21 pm Post subject: Re: Encapsulation theory |
|
|
"Ed Kirwan" <IAmFractal@hotmail.com> wrote in message
news:gesp4k$q9r$1@aioe.org...
EK> i) Minimise scope. This best practice advises that, for example, if a
EK> program unit within a subsystem is only used by other program units
EK> within
EK> the subsystem, then it should usually not be accessible outside that
EK> subsystem.
| Quote: | 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
|
Your notion of "configuration efficiency" is not that useful IMHO.
The key tenet of utility is that you make every component, and every
property of every component, publically available for use. As a result
you begin with a set of usage possibilities (U) .
You now remove from U, every element E that can be shown to
compromise the observable correctness of :
1. the entity (class etc) that E (an operation etc) belongs to
2. the existing users of E
An example of 1 would be where E is a public instance variable
representing the number of elements in a Stack object. And so on.
| Quote: | 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.
|
You misread the above. We can show both. :-)
| Quote: | 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.
|
Here is a more realistic example ...
There are two packages P1 and P2.
The package contents are :
P1_1
P2_1, P2_2, P2_3
The dependencies are :
P2_2 -|>- P2_1 -<|- P2_3
P1_1 --> P2_1
The dependency graph forms a tree. With P2_1 being the root node.
A tree is ostensibly the optimum dependency structure.
But it conflicts with the principle of package encapsulation.
If any component changes in P, then P as a whole is deemed to have changed.
All dependents of P are consequently affected, even if they don't use the
entities
that changed.
But graph theory gives us some basic tools here.
Analysis of the graph shows us that removing P2_1 from the graph makes the
graph disconnected. So P2_1 is a key component in the dependency graph.
If I redefine the packages :
P1 : P1_1
P2 : P2_2, P2_3
P3 : P3_1
the dependencies become :
P1_1 --> P3_1
P2_2 -|>- P3_1 -<|- P2_3
The dependency graph is still a tree.
But P1_1 is now decoupled from transitive dependency on P2_2 and P2_3.
Regards,
Steven Perryman |
|
