[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] [DSF] FinalLaunchSequence extensibility
|
On 07/07/2010 09:30 AM, Vladimir Prus wrote:
On Wednesday 07 July 2010 20:00:05 Pawel Piech wrote:
Another option would be to add a a Step.getID() method which would
return an optional identifier for the step (Step is an abstract class so
this would be a backward compatible change). The deriving class could
override Sequence.getSteps() and insert its own steps into the sequence
in front of or after a step with a known ID. getSteps() is called many
times, but it's assumed to be static, so the deriving class can safely
call the super-class once and then cache the modified array.
Does 'step id' have a meaning outside FinalLaunchSequence and derived
classes? If not, it's probably best to not expose this concept to
everybody, rather using some mechanisms local to FinalLaunchSequence.
Final launch sequence is probably the most advanced sequence out there
so its testing the limits of the API. Still, extensibility is something
that is likely to be applicable to other use cases of sequence so I don'
t mind creating a general solution. Of course, you could just as well
create a FinalLaunchSequcneStep abstract class or interfaces, or use
some other option that was suggested, but I wanted to point out that
adding to the base Sequence class is also on the table :-)
Unless perhaps the (private) array were replaced by a (protected)
hash, with
well-known names for the keys and the steps themselves as the values. (This
would need to be combined with a separate array to hold the ordering of the
steps.) It would then I think be quite robust to derive classes that could
refer to the standard steps known to be defined in a parent, and could modify
the inherited ordering or substitute its own altogether.
But, what happens if a step disappears, or order changes. It seems like you'll
get a runtime error, while a compile error is somewhat more convenient.
The down side of the factory approach is that it restricts the evolution
in the base class, but OTOH it makes the derived classes more reliable.
I don't know what's more important here.
Cheers,
Pawel
