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

[Ken Brady]

I'm on a team building some class libraries to be used by many other
projects.

Some members of our team insist that "All public methods should be virtual"
just in case "anything needs to be changed". This is very much against my
instincts. Can anyone offer some solid design guidelines for me?

Thanks in advance....

[Bret Pehrson]

> I'd go further: There is no reason one

would want to override a virtual function
except if one wants to change behaviour.
Please revise your statement. It should read:

There is no reason YOU would want to override ... except to change behaviour.

As I've explained several times, there *ARE* other reasons to override aside
from changing behavior. Those reasons are real and valid.
Hendrik Schober wrote:
Daniel O'Connell [C# MVP] <[e-mail]> wrote:

[...]
In everything but an idealized world, an override should be automatically
considered a change in behaviour. [...]

I'd go further: There is no reason one
would want to override a virtual function
except if one wants to change behaviour.
(Mhmm. OK, if you want to be nitpicking,
the case of overriding pure virtuals
remains to be discussed.)

[...]

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

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

--
Bret Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>

[Bret Pehrson]

> the method level, the class level, or the system level. Even if your method

looks like
public override void MyMethod()
{
base.MyMethod();
}

I would still argue that it changes the behaviour of the class, although not
significantly.
I'm still waiting to hear a (substantive) reason why this changes behavior. So
far I haven't ...
"Daniel O'Connell [C# MVP]" wrote:
"Bret Pehrson" <br**@infowest.com> wrote in message
news:40***************@infowest.com...

In everything but an idealized world, an override should be automatically considered a change in behaviour.

You have missed my point completely. I'll summarize (again), and then I'm
done.

There is more than one reason to create virtual methods:

1 - to allow a subsequent user to change behavior

2 - to allow a subsequent user to track/monitor methods or state data

*without*

modifying behavior

The point I'm trying to make is you *CANNOT* override a method without
changing behaviour, so your second point is moot, it is simply a more
specific version of the first. Overriding is a behaviour change, be it at
the method level, the class level, or the system level. Even if your method
looks like
public override void MyMethod()
{
base.MyMethod();
}

I would still argue that it changes the behaviour of the class, although not
significantly. I know what you intended to point out, I simply believe its a
false premise. If you write code with ramifications you are writing code
that changes behaviour, period(in effect, that reduces to "If you write
code, you are changing behaviour"). I simply find it silly and potentially
dangerous to decide otherwise.

There are probably other reasons as well...

Forget the example, it was merely to illustrate my point #2 above, NOT to

be a

point of endless debate on what possible ramifications trace() has on the
system, etc. ad naseum.

"Daniel O'Connell [C# MVP]" wrote:

"Bret Pehrson" <br**@infowest.com> wrote in message
news:40***************@infowest.com...
> > Simple, you do *anything* and what your class does changes.
>
> No, no, NO!
>
> Come on, my example doesn't change the behaior of the class -- period. It may
> (and very well does) change the state or behavior of the *SYSTEM*, but we are
> *not* talking about that.
If your method changes the system, then the behaviour of your class now
includes that change to the system, a classes behaviour is *EVERYTHING*, not just the class state. Even if it doesn't change the result of the call it still changes behaviour(and even in your example it *could* change the
result of the call by throwing an exception). Its likely behaviour you
*must* document, and treat as a behaviour change.

Of course, if you don't consider adding the chance of new exceptions, new ways to fail, or new possible constraints on parameters a change in
behaviour, I think our definitions of the word differ.

In everything but an idealized world, an override should be automatically considered a change in behaviour. Even if you can guarentee ironclad that it works without any behaviour change, you still leave the chance that a change *elsewhere* could change behaviour elsewhere(which is part of the problem, a code change *anywhere* is a change in behaviour, potentially in the entire system, even if its not entirely noticable or anything that actually effects change).
>
> The point was, is, and will continue to be: virtual methods can be used to
> change behavior ***OR*** for other reasons that *DO NOT CHANGE BEHAVIOR*, which
> is what I've illustrated.
>
> "Daniel O'Connell [C# MVP]" wrote:
> >
> > "Bret Pehrson" <br**@infowest.com> wrote in message
> > news:40***************@infowest.com...
> > > > This does change behaviour. (And I don't
> > > > think I want/need to tell you how.)
> > >
> > > Then don't post a response! We are (presumably) all here for
constructive
> > and
> > > educational reasons, so you statement provides nothing and actually > > confuses
> > > the issue.
> > >
> > > Please elaborate on why you think this changes class behavior. I'll > > probably
> > > learn something.
> > Simple, you do *anything* and what your class does changes. If that call > > throws an exception you are adding a point of failure, if that call
> > instantiates objects you are using memory(and perhaps creating a memory > > leak), if that call deletes random files you are probably angering
users, if
> > that call changes an object or variable the underlying method uses in > > another class you could introduce unexpected bugs and it all may rain down
> > on someone elses head because of it. Simply because your call leaves the > > instance alone does *NOT* mean that its behaviour isn't changed, its
state
> > simply isn't. Behaviour is considerably more than simply what Method A does
> > to Field B. Your example likely doesn't change the object but
potentially
> > changes the entire universe the object exists in.
> > >
> > > > I expect to read your headers, see and
> > > > recognize common patterns, understand
> > > > your identifiers, and use this interface
> > > > as it is with as little need for looking
> > > > it up in the docs as possible. If you
> > > > don't provide that, then that's one darn
> > > > good reason to look for another provider.
> > >
> > > I'm not following. Maybe my statements weren't clear, but my
intention is
> > > this: any well-meaning programmer that produces code potentially for > > anyone
> > > else (either directly or indirectly), should include complete and
correct
> > > documentation.
> > >
> > > It is extremely difficult (at best) to determine expected behavior
from
> > > prototypes and definitions alone (meaning, no documentation, *NO*
> > comments).
> > > If *you* can take naked prototypes and definitions and understand the > > usage,
> > > behavior, and characteristics of the interface, then you are in a
definite
> > > minority. Personally, I rely heavily on the documentation.
> > >
> > > Hendrik Schober wrote:
> > > >
> > > > Bret Pehrson <br**@infowest.com> wrote:
> > > > > [...]
> > > > > > The only reason to make a function virtual
> > > > > > is to allw it to be overridden. Overriding
> > > > > > a function is changing behaviour.
> > > > >
> > > > > Not true.
> > > > >
> > > > > class A
> > > > > {
> > > > > public:
> > > > > virtual void a()
> > > > > {
> > > > > // do something
> > > > > }
> > > > > };
> > > > >
> > > > > class B : public A
> > > > > {
> > > > > public:
> > > > > virtual void a()
> > > > > {
> > > > > A::a();
> > > > > trace("processing a");
> > > > > }
> > > > > }
> > > > >
> > > > > This doesn't change behavior, but is a very valid and real-world case
> > of
> > > > > virtual overrides.
> > > >
> > > > This does change behaviour. (And I don't
> > > > think I want/need to tell you how.)
> > > >
> > > > > > Don't expect us to carefully read douments
> > > > > > that contradict your code.
> > > > >
> > > > > ???
> > > > >
> > > > > I do expect you to carefully read documents that define the
behavior,
> > usage,
> > > > > and intent of my interfaces.
> > > >
> > > > I expect to read your headers, see and
> > > > recognize common patterns, understand
> > > > your identifiers, and use this interface
> > > > as it is with as little need for looking
> > > > it up in the docs as possible. If you
> > > > don't provide that, then that's one darn
> > > > good reason to look for another provider.
> > > >
> > > > > [...]
> > > >
> > > > Schobi
> > > >
> > > > --
> > > > Sp******@gmx.de is never read
> > > > I'm Schobi at suespammers dot org
> > > >
> > > > "Sometimes compilers are so much more reasonable than people."
> > > > Scott Meyers
> > >
> > > --
> > > Bret Pehrson
> > > mailto:br**@infowest.com
> > > NOSPAM - Include this key in all e-mail correspondence
<<38952rglkwdsl>>
>
> --
> Bret Pehrson
> mailto:br**@infowest.com
> NOSPAM - Include this key in all e-mail correspondence

<<38952rglkwdsl>>

--
Bret Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>

--
Bret Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>

[Hendrik Schober]

Bret Pehrson <br**@infowest.com> 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

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

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

[Bret Pehrson]

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:

Bret Pehrson <br**@infowest.com> 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

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

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

--
Bret Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>

But you have modified behaviour, you have it monitoring of events now. Thats
a modification.
"Bret Pehrson" <br**@infowest.com> wrote in message
news:40***************@infowest.com...

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:

Bret Pehrson <br**@infowest.com> 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

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

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

--
Bret Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>

[Bret Pehrson]

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?

.. wrote:

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

"Bret Pehrson" <br**@infowest.com> wrote in message
news:40***************@infowest.com...

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:

Bret Pehrson <br**@infowest.com> 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

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

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

--
Bret Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>

--
Bret Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>

[Hendrik Schober]

Bret Pehrson <br**@infowest.com> wrote:

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.
The 'B' is logging, 'A' isn't. It might be
me beeing a non-native speaker, but therefor
I would say 'B' behaves different than 'A'
does.
(And it seems hard to argue that this was
not intended, since the programmer did call
the function explicitly and I don't see any
reason for the derivation/overriding other
than to log the event.)

Also, as it was already expressed that even
calling a function that does nothing is
considered a change of behaviour, I don't
see what your point is with the above example.
[...]

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

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

[Hendrik Schober]

Bret Pehrson <br**@infowest.com> wrote:

Sorry, you are wrong.
Dot gave a reason for his/her statement,
you didn't. You won't making this any
more true by simply reapeating it.
It is not an intent to modify behavior.
Nobody doubts this. Yet it is modified.
Still 2 reasons for virtual methods, anyone want to break into the limelight
and offer a third?
I guess I'll quit this discussion now.
We have all repeated the same arguments
over and over, and you keep saying we
are wrong without making a point why
that would be so.
[...]

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

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

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.

"Bret Pehrson" <br**@infowest.com> wrote in message
news:40***************@infowest.com...

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?

. wrote:

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

"Bret Pehrson" <br**@infowest.com> wrote in message
news:40***************@infowest.com...

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:
>
> Bret Pehrson <br**@infowest.com> 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
>
> --
> Sp******@gmx.de is never read
> I'm Schobi at suespammers dot org
>
> "Sometimes compilers are so much more reasonable than people."
> Scott Meyers

--
Bret Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence

<<38952rglkwdsl>>
--
Bret Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>

[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.

.. wrote:

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.

"Bret Pehrson" <br**@infowest.com> wrote in message
news:40***************@infowest.com...

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?

. wrote:

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

"Bret Pehrson" <br**@infowest.com> wrote in message
news:40***************@infowest.com...
> 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:
> >
> > Bret Pehrson <br**@infowest.com> 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
> >
> > --
> > Sp******@gmx.de is never read
> > I'm Schobi at suespammers dot org
> >
> > "Sometimes compilers are so much more reasonable than people."
> > Scott Meyers
>
> --
> Bret Pehrson
> mailto:br**@infowest.com
> NOSPAM - Include this key in all e-mail correspondence

<<38952rglkwdsl>>

--
Bret Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>

--
Bret Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>

[Martin Maat [EBL]]

"Bret Pehrson" <br**@infowest.com> wrote in message
news:40***************@infowest.com...

I would still argue that it changes the behaviour of the class, although not significantly.

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]

"Bret Pehrson" <br**@infowest.com> wrote in message
news:40***************@infowest.com...

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]

"Martin Maat [EBL]" <du***@somewhere.nl> wrote in message
news:10*************@corp.supernews.com...

"Bret Pehrson" <br**@infowest.com> wrote in message
news:40***************@infowest.com...

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.

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 :D 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.
"Martin Maat [EBL]" <du***@somewhere.nl> wrote in message
news:10*************@corp.supernews.com...

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.