The graphical rules editor used in the UI generates a class, and an xml block in that class, to represent your rules.
If you want a target to be different, based on some code, why don't you create multiple conditions for the different targets you have, then, base each condition on some database setting.
The rule itself remains static (except when you need to define a new target) and it will show all the possible paths that can be taken by the rule.
Then.. programatically...you change that value in the database which is behind all the conditional statements you have and thus - programatically, you effect a target change.
The other alternative is to use a Business Process. You can send your message to be handled and routed by a Business Process in BPL. The process, can programatically resolve the name of the target component in a context variable (let's say, context.TargetName). After context.TargetName has been programatically resolved, make a BPL Call action, and for the Call action's property "target" don't hardcode a value.
Instead supply "@context.TargetName", and the message will be sent to whatever the value of context.TargetName is at that point in time.