"All public methods should be virtual" - yes or no / pros & cons

[Bret Pehrson]

I don't care about the IL -- I'm talking about design. I can't get much more
plain than what I've already said.

So, it still stands, there are 2 reasons for virtual methods.

There maybe no INTENT but you sure did modify it, B.OnStartup is no way the
same as A.OnStartup, it maybe similar but its not the same method.

If you see it as the same method where do you buy your glasses? The very
monitoring of events call is a modification. Check the IL its NOT the same.

Sorry, you are wrong. It is not an intent to modify behavior.

Still 2 reasons for virtual methods, anyone want to break into the limelight
and offer a third?

But you have modified behaviour, you have it monitoring of events now. Thats
a modification.

Dude, you need to stop being so explicit w/ this topic.

Here is another example, where behavior is NOT changed:

class A
{
protected:
virtual void OnStartup() { }
};

class B : public A
{
protected:
virtual void OnStartup() {
log_event_no_exceptions_or_performance_penalties(); }
};

Now, if you would just look at this as the *INTENT* to not modify
behavior, but
to monitor events, you now have, get this, another reason for virtual
methods.

Let me revise my original statement (way back when):

Overriding serves multiple purposes:

- the INTENT to modify behavior

- the INTENT to monitor events (without the INTENT to modify behavior)

- probably other reasons

Is there anyone else out there reading this thread that agrees w/ me???


Hendrik Schober wrote:

Don't you consider performance to be
observable behaviour?

Performance is a *characteristic*, not a behavior.

If your program misses data on a serial
port due to this, it changes behaviour.
So a performance change _is_ a behaviour
change.

For the life of me, I can't figure out why no one seems to be able to
understand that there is more than one reason (change of behavior) for
virtual
methods.

Probably because there isn't?

[...]

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

 

[Martin Maat [EBL]]

I'm still waiting to hear a (substantive) reason why this changes behavior. So
far I haven't ...

Can we stop this now please? Bret is, although besides the point, basically
right discriminating between behavior and characteristics. If you are
thinking strictly OO though there's only data and behavior and any change to
a method is a change in behavior. The discussion is pointless, the initial
statement wasn't even focussing on behavior as such but rather on the
question whether it would be appropriate to use a virtual method (primarily
a means to express polymorphism) as a plug-in mechanism. Should we use it
for delegation or even event purposes that not necessarily change behavior
in a polymorphic or specializing sense?

If I walk up to my fridge one day to have breakfast and the next morning I
do the same but I limp because I hurt myself in the meantime, did my
behavior change? Technically, yes. Logically, no.

If you use a private method with the purpose of plugging in a log action you
are not changing your OO-model in the sense that you are not specializing
nor expanding your base type's behavior as far as its problem domain is
concerned nor are you creating a new incarnation of it. This is why I feel
it is in this case inappropriate to use a virtual method in the first place
because virtual methods are typically strongly associated with and meant to
be used for implementing the very features that do not apply in this case.

Anyway, you can all be right depending on the level onto which you want to
apply your statement about behavior. To technical level participants
behavior changes, to problem domain level participants behavior does not
necessarily change. No let's make up and start a more interesting issue to
disagree on.

Martin.

 

[Magnus Lidbom]

I don't care about the IL -- I'm talking about design. I can't get much more
plain than what I've already said.

So, it still stands, there are 2 reasons for virtual methods.

Noone doubt's that it's is possible to override a method without the
explicit intent to modify behavior. That doesn't change the fact that
overriding a method does change behavior.
I believe your mistake is confusing the return value, or stated purpose, of
a method with the entirety of the consequences of the implementation of the
method. In many cases the changes in behavior that your examples will cause
is irrelevant, but it's still there.

/Magnus Lidbom

 

[Magnus Lidbom]

If you use a private method with the purpose of plugging in a log action you
are not changing your OO-model in the sense that you are not specializing
nor expanding your base type's behavior as far as its problem domain is
concerned nor are you creating a new incarnation of it. This is why I feel
it is in this case inappropriate to use a virtual method in the first place
because virtual methods are typically strongly associated with and meant to
be used for implementing the very features that do not apply in this case.

Public virtuals, yes. Protected, no.
If something in the public interface of a class is virtual it's a statement
that the implementation of that member may be replaced. Using a protected
virtual to allow extentions of the sort discussed in this thread does not
modify the contract implicitly defined by a class's public interface. If you
have a reason why an implementaion like below would be inappropriate I'd
like to hear it:

class Base
{
public void DoStuff()
{
//Check invariants
//Do stuff:
ExtendDoStuff();
//Check invariants
}

protected virtual void ExtendDoStuff()
{
}
}

class Inhertiting : Base
{
protected override void ExtendDoStuff()
{
//Log something.
}
}

Anyway, you can all be right depending on the level onto which you want to
apply your statement about behavior. To technical level participants
behavior changes, to problem domain level participants behavior does not
necessarily change. No let's make up and start a more interesting issue to
disagree on.

How about the above?

/Magnus Lidbom

 

[Martin Maat [EBL]]

If you have a reason why an implementaion like below would be

inappropriate I'd like to hear it:

class Base
{
public void DoStuff()
{
//Check invariants
//Do stuff:
ExtendDoStuff();
//Check invariants
}

protected virtual void ExtendDoStuff()
{
}
}

class Inhertiting : Base
{
protected override void ExtendDoStuff()
{
//Log something.
}
}

Because you are basically implementing an event, not extending problem
domain behavior as the method's name suggests. So it would be more
appropriate to use an event, to implement some sort of callback in the base
class (C# delegate). Your example and all of the others provided earlier to
convince us that behavior is changed or behavior is not changed are using
inheritence for the wrong reasons.

It is purely academic of course but hey, that's what we're her for.

Martin.

 

[Guest]

If the team wants everything virtual, fc.uk em, what I do now is when people
are persistant, I just give them what they cry for, S.hite design
implementation. When the shit hits the fan , fingers get pointed If I
want something done a certain way, I do that at home.

If a company wants a s.hit product, I can equally give them that if they
p.iss me off.