|
| Re: Base Imports [message #531151 is a reply to message #531139] |
Mon, 03 May 2010 21:39   |
 Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
OK, one answer at a time:
| Jan Marc Hoffmann wrote on Mon, 03 May 2010 16:35 | Hi all,
I have 2 small design question. Why are there two different imports? regular java imports and base imports? And why cant I base import and import the same class? (using fqn sucks ;P)
|
When you bind a role R to a base class B you have some privileges
(decapsulation, callin) that normal Java rules wouldn't grant.
However, I don't want those privileges to "leak", i.e., only the role binding
can make use of decapsulation. The role should then act as the single point
of access towards B.
From this you gain the following guarantees: If you want to find out about
any privileged access to B all you need to inspect are the callout/callin
bindings of role R. Secondly you avoid the confusion that would occur
if you try to compare (==) a role with its base. Should they be considered
the same object? By the OT/J scoping rules such mixed comparison
will generally be impossible, because normally no context has references
to both R and B instances.
The compile checks required for these guarantee are based on the
distinction between regular and base imports, because with a base import
you say: I don't want to directly access this class but only bind a role.
As mentioned, inside R's team all access to B should now go via R.
So I would be curious, if you really need addtional normal access to B,
why would that be? Is that some design that can perhaps be improved to
follow the single point of access rule? Can you give an example?
These rules may force you to think twice, but I believe that this will pay
off, resulting in a design that's easier to maintain etc.
best,
Stephan
|
|
|
|
| Re: Base Imports [message #574077 is a reply to message #531139] |
Mon, 03 May 2010 21:39 |
Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
OK, one answer at a time:
Jan Marc Hoffmann wrote on Mon, 03 May 2010 16:35
> Hi all,
>
> I have 2 small design question. Why are there two different imports? regular java imports and base imports? And why cant I base import and import the same class? (using fqn sucks ;P)
When you bind a role R to a base class B you have some privileges
(decapsulation, callin) that normal Java rules wouldn't grant.
However, I don't want those privileges to "leak", i.e., only the role binding
can make use of decapsulation. The role should then act as the single point
of access towards B.
From this you gain the following guarantees: If you want to find out about
any privileged access to B all you need to inspect are the callout/callin
bindings of role R. Secondly you avoid the confusion that would occur
if you try to compare (==) a role with its base. Should they be considered
the same object? By the OT/J scoping rules such mixed comparison
will generally be impossible, because normally no context has references
to both R and B instances.
The compile checks required for these guarantee are based on the
distinction between regular and base imports, because with a base import
you say: I don't want to directly access this class but only bind a role.
As mentioned, inside R's team all access to B should now go via R.
So I would be curious, if you really need addtional normal access to B,
why would that be? Is that some design that can perhaps be improved to
follow the single point of access rule? Can you give an example?
These rules may force you to think twice, but I believe that this will pay
off, resulting in a design that's easier to maintain etc.
best,
Stephan
|
|
|
|
Powered by
FUDForum. Page generated in 0.03435 seconds
] 
Search
Help
Register
Login
Home
