> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
>
> > 1. (String)context.get( "name.key" );
> > 2. ((NameContext)context).getName();
>
> As I believe I have repeatedly pointed out, these are not
> equivalent.
>
> This extends to objects that provide services, not just
> simple data types. IMO, the access mechanism provided to
> components should be DECOUPLING from implementations, not
> COUPLING via inheritance.
In what way does (2) have stronger coupling? Since there is logical
equivalence between having a "name.key" entry and a NameContext
interface:
Context has a "name.key" entry <-> Context implements NameContext
There is no stronger coupling, as I see it. I could even argue that (2)
has less coupling, as you access items via type-safe accessors instead
of a type-unsafe map, giving (2) two advantages:
+ return type is checked by compiler. (The (String) cast can't)
+ name of method is checked by compiler. ("name.key" isn't)
Part of this effort is to see if it is possible to get away from the
hyper-abstract interface Context interface we have now. After all,
since we don't design our objects like this:
public class MyClass {
public Object performOperation (Object op) { ... };
}
There is no need to have a:
public interface Context {
public Object get (String);
}
for bean-like objects.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
