On Wed, Feb 2, 2011 at 4:10 PM, Emmanuel Lecharny <elecha...@gmail.com> wrote:
> I forgot to mention that the BasicControl is inherited by 6 controls. This
> should also be changed, having all the controls inheriting from an
> AbstractControl class.
Just to recap our discussion from IRC. I find value in using the
abstract class if you need it to make final some methods you don't
want overridden by subtypes.
You mentioned though something subtle. That you would like there to be
a distinction between two kinds of Controls produced by the codec
service:
(1) Controls, that are not recognized by the codec and hence their
values are treated as opaque binary data. This situation arises when
the codec does not have a Control factory registered for that
Control's OID. In this situation, the codec cannot decode or encode
this Control's binary value. It just handles it by default this way to
enable pass-thru situations where the Control's value is passed up to
application logic for handling or handed off as-is to some other
(internal or external) [sub]system.
(2) Registered Control factories, will supply Control extending
interfaces exposing the Control value's internal structure with
property accessors. Just as an example consider the Subentry control:
public interface ISubentries extends Control
{
String OID = "..."
void setVisibility( boolean visibility );
boolean isVisibile();
}
AFAIU, you want to differentiate between controls in case #1 above
whose values are treated as opaque binary data, verses the base class
from which all Control subtype implementations extend.
If I understand correctly, then the abstractness is not the point. Let
me suggest this alternative.
(1) For case #1 above, create a final (non-extendable) Control
implementation class called OpaqueControl which also contains the
additional getValue()/setValue()/hasValue() methods. We will use this
control only for Controls we cannot handle the value of, as the
default condition in the codec factory. This control can be in the
model under pakcage oadl.message.controls.
(2) For case #2 above, create a concrete Control implementation
class called BaseControl. This control should be part of the codec SPI
instead of in the model. It should not even be exposed by the codec
API IMO.
APPROACH BENEFITS
------------------------------------
o Users intuit the OpaqueControl is one whose value cannot be handled.
o The final OpaqueControl class prevents users from accidental extension.
o Code that cannot access the codec, yet has access to the encoded
value for all practical purposes see that control as opaque, if they
need to such code can use this class to encapsulate the value to
interface with code requiring subtypes of the model's Control
interface, the codec can convert it if need be deep below. This is the
only exception to the visibility of the value property and this way it
is OK.
o The BaseControl is hidden and can only be used by codec
extenders as part of the SPI
o When the codec cannot handle a control it creates the OpaqueControl type.
On another note we might need a final OpaqueControlDecorator which
does not need to keep a value member as it's own member but can access
the value via OpaqueControl.getValue().
WDYT?
Best,
- Alex
