473,842 Members | 1,933 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

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

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....
Nov 15 '05
175 8932
> Don't you consider performance to be
observable behaviour?
Performance is a *characteristic *, not a behavior.

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.
Hendrik Schober wrote:
ozbear <oz*****@yahoo. com> wrote:
On Sun, 1 Feb 2004 02:53:28 -0600, "Daniel O'Connell [C# MVP]"
<onyxkirx@--NOSPAM--comcast.net> wrote:
[...] 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.


<snip>

How?

Aside from rather mundane things like a few spare clock cycles to
perform the extra method call, if a client/calling method cannot
tell, from the *result* of invoking the overriden method, that the
method was, in fact, overriden, exactly in what way has the
/behaviour/ been changed?


Don't you consider performance to be
observable behaviour? I find it rather
easy to imagine a case where the above
change could render a whole app useless
due to the performance loss. And while
I can't imagine it, my experience with
that Murphy guy insists that this can
indeed happen where I'm sure it never
would. And I learned to trust this
Murphy experience over the years more
than my own judgements. :)
Oz


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**@inf owest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>
Nov 15 '05 #161
> 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] <onyxkirx@--NOSPAM--comcast.net> 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**@inf owest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>
Nov 15 '05 #162
> 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******** *******@infowes t.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******** *******@infowes t.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******** *******@infowes t.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("processi ng 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**@inf owest.com
> > > NOSPAM - Include this key in all e-mail correspondence
<<38952rglkwdsl >>
>
> --
> Bret Pehrson
> mailto:br**@inf owest.com
> NOSPAM - Include this key in all e-mail correspondence

<<38952rglkwdsl >>

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


--
Bret Pehrson
mailto:br**@inf owest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>
Nov 15 '05 #163
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
Nov 15 '05 #164
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_ex ceptions_or_per formance_penalt ies(); }
};

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**@inf owest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>
Nov 15 '05 #165
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******** *******@infowes t.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_ex ceptions_or_per formance_penalt ies(); }
};

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**@inf owest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>

Nov 15 '05 #166
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******** *******@infowes t.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_ex ceptions_or_per formance_penalt ies(); }
};

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**@inf owest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>


--
Bret Pehrson
mailto:br**@inf owest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>
Nov 15 '05 #167
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_ex ceptions_or_per formance_penalt ies(); }
};

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
Nov 15 '05 #168
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
Nov 15 '05 #169
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******** *******@infowes t.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******** *******@infowes t.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_ex ceptions_or_per formance_penalt ies(); }
};

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**@inf owest.com
NOSPAM - Include this key in all e-mail correspondence

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

Nov 15 '05 #170

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

164
8069
by: Ken Brady | last post by:
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....
0
9870
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9715
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
1
10671
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10310
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9452
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
7035
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5696
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
2
4088
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3142
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.