Or, if the behavior you are trying to invoke can be logically refactored into the objects, then you could call it virtually against the object, in which case it would get dispatched to the correct implementation. Looks like basically you are trying to get virtual call semantics outside the scope of the object hierarchy, which is not really built in.
All I can think of off the top of my head is some messy conditional selection based on typeof, which isn't what you want.
Ron: Your solution defeates the purpose :)
I even tries using
[MethodImpl(MethodImplOptions.NoInlining)]
on the method, but no luck. Funny - logically it seems that me that one would have worked..
Doh! Brian already said the same thing earlier.
> logically it seems that me that one would have worked.
method inlining is something completely different. it has nothing to do with the target call site being resolved at compile time. method inlining is embedding the target call site within the caller to remove a stack frame.
what you are asking is to have the runtime execute automatically the code Ron supplied as a default behavior without manually writing it, which is quite undesirable. I certainly don't want the runtime to traverse through the inheritance tree of every parameter to figure out if there's another "better" fit overload to call.
Aren't situations like these the entire reasons that languages like Python exist?
Eg, the cast-o-rama and related problems associated with static typing?
Looks like a good place for either:
Template Method pattern
Strategy pattern
The first for simplicity.
The second if you want to reduce type explosion and allow future where you could have more than one strategy per employee.
my code looked almost exactly like Mr Hebben's. I agree that it seems a little backwards that the original sample had object-specific behaviors (doSomething()) that were seperate from the objects themselves.
Perhaps I missed the point?
When the behavior you want to introduce is part of the domain you are modeling, then indeed refactoring the method into the person base class is a viable solution. However, say you want to select the correct VIEW for an object based on an overload:
Control SetView(Manager manager)
{...}
Control SetView(Employee employee)
{...}
In that case, I think you can hardly move this logic into the base class (since the domain object should not have knowledge of any view stuff, should it?). In some cases, a possible solution (albeit not a 100% clean either :() is to use the visitor pattern. That way, the person base class contains a method like
abstract void SupplyInfo(IInterested interested);
and each concrete class can decide what information it will pass to the IInterested interface implementer. The strength in that implementation is that the information can be supplied to anyone who implements the IInterested interface, so not necessarily to a view.
To clarify what I mean with "not 100% clean" :
Of course, in the problem stated in my previous comment, you still need to SELECT the right view that implements the IInterested interface and that you supply to the SupplyInfo method. You could do this based on a map or dictionary that contains a mapping of types on views. This mapping can e.g. be managed by a factory.
In other possible cases, the same view is used for a range of different objects. In that case, you don't need the view mapping, and simply pass in the unique view.