c# - Implementing "Fallback" Classes -

i have set of classes, each of need decide @ point of 2 or 3 approaches should use internally implement same functionality externally. ideally, should include fallback functionality, if approacha fails, falls through try approachb (and perhaps approaches c, d, etc.). until now, i've been using coding if (!success) { approachb code }. problem several later methods need aware of approach chosen , of them develop own if (methodchosen) { } else { } statements well. want address issue less unwieldy...except none of other options i've considered seems "wieldy". here 3 approaches thought of:

1. implement static .create method decides of 2 derived classes create, 2 classes have interface backing them. disadvantage of you're writing lot of same code twice, , it's not creating "fallback" since forces decision-making done front in .create method. should work 9/10 times, there'll other 1/10 times want fallback kick in when primary has tried , failed.
2. the same above, base or abstract class involved, either backing class both, or primary base class fallback. has same fallback disadvantage, @ least there's little or no repeated code.

3. implement normally-constructed abstract class child classes can changed @ run-time: i.e.

   public void somemethodorconstructor() {     if (someconditions)         mychild = childclassa;     else         mychild = childclassb; }   public void execute() {     mychild.execute(); } 

the problem option 3 passing data between 2 when needed. since of these methods modelling outside objects, that'll frequent. nested classes share data parent class automatically? or have pass every call?

anything else should consider?

---

update: first class , running chain of responsibility. now, i've opted not use strategy pattern or fallback during method execution, believe may unnecessary in end. think such execution-fallbacks better off staying within own classes, since there won't complete change of gameplan, few minor tweaks deal with. if turns out not case, @ least know need investigate now.

thanks helped ultimate solution!

for curious, ultimate solution worked this:

• create handler abstract class, pretty outlined in wikipedia article, public abstract handler gethandler() function, , adding other abstract methods load, save, etc.
• implement private handler sub-classes parent class (they might sub-classes, since they'll handling things particular class...avoids later naming issues too). child classes take parameter of parent object's type in constructor, have easy access parent's data.
• from parent class's constructor, setup chain of responsibility handlers/successors (again, example), call firsthandler.gethandler(this) , store result class knows handler use in future.
• most handled methods reduce handler.methodname().

use chain of responsibility.

chain-of-responsibility pattern design pattern consisting of source of command objects , series of processing objects. each processing object contains set of logic describes types of command objects can handle, , how pass off cannot handle next processing object in chain. mechanism exists adding new processing objects end of chain.

this fits need do.