responding to Rhythm *** ...
Yes, the Strategy pattern will let you do that.
The basic issue is:
* R1 uses 1
[Validator] --------------------- [ValidationStrategy]
The R1 association will be instantiated based on what type of user is
being validated. Whoever does that will usually know what type of user
is in hand (e.g., a userType attribute in a [User] object).
IOW, by the time you need to do privilege validation, the context
information will usually already be in the instantiated objects.
similarly, the [ValidationStrategy] objects only need to access
attribute data to do their thing.
Quite often instantiating R1 will be done when the User object is
instantiated (perhaps from the DB) by a factory object of some sort.
That factory object would have a lookup table based on userType that
would yield the correct subclass references for the [ValidationStrategy]
to use in instantiating the association. That lookup table would in
initialized when the factory object is instantiated, usually at startup.
(That, in turn, implies that the [ValidationStrategy] objects are
That initialization will usually be more robust if it is defined in
external configuration data (e.g., in the DB). Basically one needs a
table that maps userType to a strategyType attribute in
[validationStrategy]. (Since you only need one object of each subclass,
strategyType doubles as an explicit identifier.) IOW, the thing you get
from the DB is the lookup table for instantiating R1, usually at startup.
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
"Model-Based Translation: The Next Step in Agile Development". Email
XXXX@XXXXX.COM for your copy.
Pathfinder is hiring: