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.