R
Roedy Green
If you come from a Forth background or something similar, it is
trivially easy to change even the most fundamental behaviours of the
runtime. There is no safety net to prevent suicidal behaviours.
Let's say you wanted to do something like add some extra fields to the
File object. So long as File is not final, you can subclass it and
create all the FilePlus objects you want.
However, everywhere else File objects still get created without the
extra fields. Every time you encounter one, you have to tediously
convert it to a FilePlus. Would it not be nice if you could persuade
the system to create FilePlus objects directly instead of File Objects
when someone asked for a File object.
That would be considered hideously dangerous and wicked. Ok, what if
the authors of File had foreseen this eventuality, and made the
constructor for File private and offered a factory method instead to
produce the desired File objects.
But that does not get you anywhere. You can't replace a static
factory method, and no one but you would use an overridden one.
You actually need a static factory method that fobs the work off on a
static reference delegate factory object. There needs also to be a
setFactory method to change the factory object, and off course a
Factory Interface for the factory object to implement.
Whew. I think that is what is happening inside the Java Security
system with pluggable implementations.
trivially easy to change even the most fundamental behaviours of the
runtime. There is no safety net to prevent suicidal behaviours.
Let's say you wanted to do something like add some extra fields to the
File object. So long as File is not final, you can subclass it and
create all the FilePlus objects you want.
However, everywhere else File objects still get created without the
extra fields. Every time you encounter one, you have to tediously
convert it to a FilePlus. Would it not be nice if you could persuade
the system to create FilePlus objects directly instead of File Objects
when someone asked for a File object.
That would be considered hideously dangerous and wicked. Ok, what if
the authors of File had foreseen this eventuality, and made the
constructor for File private and offered a factory method instead to
produce the desired File objects.
But that does not get you anywhere. You can't replace a static
factory method, and no one but you would use an overridden one.
You actually need a static factory method that fobs the work off on a
static reference delegate factory object. There needs also to be a
setFactory method to change the factory object, and off course a
Factory Interface for the factory object to implement.
Whew. I think that is what is happening inside the Java Security
system with pluggable implementations.