473,842 Members | 1,945 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
"Martin Maat [EBL]" <du***@somewher e.nl> wrote in message
news:10******** *****@corp.supe rnews.com...
Well, they didn't have these fancy editors back then that enabled the
programmer to collaps the implemantation did they? So seperating interface and implementation was just practical [...]
If I hadn't been taught it before, the first time I came across an app

that
had a couple 100kLOC, with many people designing and implementing
parts of it simultaniously, I know what separation of interface and
implementation is good for. IMHO that's why so many languages
have it.


No, don't mean a thing. What you are refering to is having separate
(implementation ) code files for different parts of a system. That is a

good thing. Implementation and interface though, beit for a single class or for
any code library, are logically one and the same. Seperating them physically does not bring any gain as far as maintainability is concerned. You will
always lock both when working on either. Working on just the interface
without touching the implementation is pointless and if you are changing the implementation you don't want anyone else to mess with the interface. If
anyone did want to mess with the interface he would most certainly want to
mess with the implementation as well. [...] Martin.


I like a seperate file with an overview of what your interface for a class
is (speaking about implementation of classes). Now that I code JAVA
sometimes, I really miss the headers, and the feeling doesn't go away.

The problem is that such an overview cannot be generated from just a source
file, because it isn't stable and could contain bugs that do not allow it to
be generated. A side bar with an alfabetically sorted list with members and
stuff is to my feeling not enough. A header file that groups functionality
and members etc gives me a nicer overview.

And as for the locking, a lot of times I (or my colleagues) lock the
implementation file during debug phases.

Tom.
Nov 15 '05 #101
"Martin Maat [EBL]" <du***@somewher e.nl> wrote in message
news:10******** *****@corp.supe rnews.com...
Well, they didn't have these fancy editors back then that enabled the
programmer to collaps the implemantation did they? So seperating interface and implementation was just practical [...]
If I hadn't been taught it before, the first time I came across an app

that
had a couple 100kLOC, with many people designing and implementing
parts of it simultaniously, I know what separation of interface and
implementation is good for. IMHO that's why so many languages
have it.


No, don't mean a thing. What you are refering to is having separate
(implementation ) code files for different parts of a system. That is a

good thing. Implementation and interface though, beit for a single class or for
any code library, are logically one and the same. Seperating them physically does not bring any gain as far as maintainability is concerned. You will
always lock both when working on either. Working on just the interface
without touching the implementation is pointless and if you are changing the implementation you don't want anyone else to mess with the interface. If
anyone did want to mess with the interface he would most certainly want to
mess with the implementation as well. [...] Martin.


I like a seperate file with an overview of what your interface for a class
is (speaking about implementation of classes). Now that I code JAVA
sometimes, I really miss the headers, and the feeling doesn't go away.

The problem is that such an overview cannot be generated from just a source
file, because it isn't stable and could contain bugs that do not allow it to
be generated. A side bar with an alfabetically sorted list with members and
stuff is to my feeling not enough. A header file that groups functionality
and members etc gives me a nicer overview.

And as for the locking, a lot of times I (or my colleagues) lock the
implementation file during debug phases.

Tom.
Nov 15 '05 #102
> > Implementation and interface though, beit for a single class or for
any code library, are logically one and the same. Seperating them physically does not bring any gain as far as maintainability is concerned.
It does. It makes clients independand of
the implementation. They only depend on
the interface.
It is not the physical separation of interface and implementation that makes
clients independent of a class's implementation, it is you not messing with
the interface that makes clients independent of the implementation.
I rarely ever change a header.
(I'd be dead within a week if I did change
interfaces half as often as I change their
implementations . People would be queueíng
at the table tennis room while their
machines are locked with the compiler
running and had a _lot_ of time to consider
what bad things to do to me. :o> )
And your point is? Whether you change interfaces a lot or not highly depends
on the fase of the project and on your role in it. If your interfaces are
established, good for you.
Working on just the interface
without touching the implementation is pointless and if you are changing the implementation you don't want anyone else to mess with the interface. If
anyone did want to mess with the interface he would most certainly want to mess with the implementation as well.


Althoguh I think it is possible, it is uncommon to lock
files using CVS. I have never done it and haven't heard
from anyone doing it here.


I am not sure what you mean with CVS. When I say "lock" I am refering to a
source control system like SourceSafe, MKS or PVCS.

You should lock both interface and implemantation to make sure no one else
will change the interface while you are working on the implementation. They
are one. I know that it is unlikely someone will, I was just making the
point that interface and implementation are logically one (we are still
talking source code for a class).
Mind that the idea of .c and .h files stems from the pre-OO days. People
mainly extended that to .cpp and .h because they were used to working that way. For class definitions there is no point in doing so as far as
maintainability is concerned..


You're kidding, aren't you?
Suppose I have a class 'X', used in just
about every part of a big project. Now I
found a bug in 'X::f()' and need to fix
that. Why would I need to lock/change the
interface?


Just lock, not change.
With C# it is not only because there is no longer a practical need for
separation that everything is in one file now, it is a design decision based on the notion that a class definition is a self-contained unit. Think of the problems that would arise for the namespace system if it were different.

I don't know C# and I don't know its
namespace system. What I know is this: If
I cause everybody here to recompile just
because I fix some implementation, I'd
be in serious trouble.


We don't have a disagreement, you just misunderstood what I was saying.
Joining interface and implementation in one file does not break the
interface when you update the implementation.

Martin.
Nov 15 '05 #103
> > Implementation and interface though, beit for a single class or for
any code library, are logically one and the same. Seperating them physically does not bring any gain as far as maintainability is concerned.
It does. It makes clients independand of
the implementation. They only depend on
the interface.
It is not the physical separation of interface and implementation that makes
clients independent of a class's implementation, it is you not messing with
the interface that makes clients independent of the implementation.
I rarely ever change a header.
(I'd be dead within a week if I did change
interfaces half as often as I change their
implementations . People would be queueíng
at the table tennis room while their
machines are locked with the compiler
running and had a _lot_ of time to consider
what bad things to do to me. :o> )
And your point is? Whether you change interfaces a lot or not highly depends
on the fase of the project and on your role in it. If your interfaces are
established, good for you.
Working on just the interface
without touching the implementation is pointless and if you are changing the implementation you don't want anyone else to mess with the interface. If
anyone did want to mess with the interface he would most certainly want to mess with the implementation as well.


Althoguh I think it is possible, it is uncommon to lock
files using CVS. I have never done it and haven't heard
from anyone doing it here.


I am not sure what you mean with CVS. When I say "lock" I am refering to a
source control system like SourceSafe, MKS or PVCS.

You should lock both interface and implemantation to make sure no one else
will change the interface while you are working on the implementation. They
are one. I know that it is unlikely someone will, I was just making the
point that interface and implementation are logically one (we are still
talking source code for a class).
Mind that the idea of .c and .h files stems from the pre-OO days. People
mainly extended that to .cpp and .h because they were used to working that way. For class definitions there is no point in doing so as far as
maintainability is concerned..


You're kidding, aren't you?
Suppose I have a class 'X', used in just
about every part of a big project. Now I
found a bug in 'X::f()' and need to fix
that. Why would I need to lock/change the
interface?


Just lock, not change.
With C# it is not only because there is no longer a practical need for
separation that everything is in one file now, it is a design decision based on the notion that a class definition is a self-contained unit. Think of the problems that would arise for the namespace system if it were different.

I don't know C# and I don't know its
namespace system. What I know is this: If
I cause everybody here to recompile just
because I fix some implementation, I'd
be in serious trouble.


We don't have a disagreement, you just misunderstood what I was saying.
Joining interface and implementation in one file does not break the
interface when you update the implementation.

Martin.
Nov 15 '05 #104
> I like a seperate file with an overview of what your interface for a class
is (speaking about implementation of classes). Now that I code JAVA
sometimes, I really miss the headers, and the feeling doesn't go away. The problem is that such an overview cannot be generated from just a source file, because it isn't stable and could contain bugs that do not allow it to be generated. A side bar with an alfabetically sorted list with members and stuff is to my feeling not enough. A header file that groups functionality
and members etc gives me a nicer overview.


I haven't done any substantial C# project yet so I didn't feel it yet but I
may feel the same in the near future. I hope I will just get used to it,
syntax has become clearer in the way that things are being declared loaclly,
less surprises or pitfalls. But I agree the overall code image seems to have
suffered. For one thing, I prefer this:

TMyThingy = class(TObject)
private:
Field1 :integer;
Field2 :string;
procedure method1();
procedure method2();
protected:
procedure method3();
public:
constructor Create
destructor Destroy;
procedure method4();
end;
over this:
TMyThingy = class(TObject)
private Field1 :integer;
private Field2 :string;
private procedure method1();
private procedure method2();

protected procedure method3();

public constructor Create
public destructor Destroy;
public procedure method4();
end;
The sections are lost, it's not pretty! :-(

Martin.
Nov 15 '05 #105
> I like a seperate file with an overview of what your interface for a class
is (speaking about implementation of classes). Now that I code JAVA
sometimes, I really miss the headers, and the feeling doesn't go away. The problem is that such an overview cannot be generated from just a source file, because it isn't stable and could contain bugs that do not allow it to be generated. A side bar with an alfabetically sorted list with members and stuff is to my feeling not enough. A header file that groups functionality
and members etc gives me a nicer overview.


I haven't done any substantial C# project yet so I didn't feel it yet but I
may feel the same in the near future. I hope I will just get used to it,
syntax has become clearer in the way that things are being declared loaclly,
less surprises or pitfalls. But I agree the overall code image seems to have
suffered. For one thing, I prefer this:

TMyThingy = class(TObject)
private:
Field1 :integer;
Field2 :string;
procedure method1();
procedure method2();
protected:
procedure method3();
public:
constructor Create
destructor Destroy;
procedure method4();
end;
over this:
TMyThingy = class(TObject)
private Field1 :integer;
private Field2 :string;
private procedure method1();
private procedure method2();

protected procedure method3();

public constructor Create
public destructor Destroy;
public procedure method4();
end;
The sections are lost, it's not pretty! :-(

Martin.
Nov 15 '05 #106
Martin Maat [EBL] <du***@somewher e.nl> wrote:
[...] It makes clients independand of
the implementation. They only depend on
the interface.
It is not the physical separation of interface and implementation that makes
clients independent of a class's implementation, it is you not messing with
the interface that makes clients independent of the implementation.


So when you checkin a c# file that you
have changed without changing anything
of the interface, does everybody have
to recompile the dependend modules?
I rarely ever change a header.

[...]

And your point is? [...]


Why should I lock a header if I won't
change it???
Working on just the interface
without touching the implementation is pointless and if you are changing the implementation you don't want anyone else to mess with the interface. If
anyone did want to mess with the interface he would most certainly want to mess with the implementation as well.


Althoguh I think it is possible, it is uncommon to lock
files using CVS. I have never done it and haven't heard
from anyone doing it here.


I am not sure what you mean with CVS. When I say "lock" I am refering to a
source control system like SourceSafe, MKS or PVCS.


CVS, the version control system.
(www.cvshome.org)
After years of trouble with VSS, we
switched to CVS. I was not happy about
that decision back then (although I
wanted to get rid of VSS as soon as
possible). But I learned to like CVS.
You should lock both interface and implemantation to make sure no one else
will change the interface while you are working on the implementation. They
are one. I know that it is unlikely someone will, I was just making the
point that interface and implementation are logically one (we are still
talking source code for a class).
As I said, I never lock anything. If
anyone changed anything I was working
on, I merge this into my local version
(and test it) before I checkin the
file(s).
[...]
Suppose I have a class 'X', used in just
about every part of a big project. Now I
found a bug in 'X::f()' and need to fix
that. Why would I need to lock/change the
interface?
Just lock, not change.


Why would I need to lock the interface?
[...]
Joining interface and implementation in one file does not break the
interface when you update the implementation.
I don't know if C# prevents recompilation
of dependend modules if you change a module
without changing any declarations. Maybe it
does so.
However, with the interface/implementation
separated, you have a nice check to make
sure you didn't change anything accidentally,
as your implementation most often won't
compile if you did.
Martin.

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 #107
Martin Maat [EBL] <du***@somewher e.nl> wrote:
[...] It makes clients independand of
the implementation. They only depend on
the interface.
It is not the physical separation of interface and implementation that makes
clients independent of a class's implementation, it is you not messing with
the interface that makes clients independent of the implementation.


So when you checkin a c# file that you
have changed without changing anything
of the interface, does everybody have
to recompile the dependend modules?
I rarely ever change a header.

[...]

And your point is? [...]


Why should I lock a header if I won't
change it???
Working on just the interface
without touching the implementation is pointless and if you are changing the implementation you don't want anyone else to mess with the interface. If
anyone did want to mess with the interface he would most certainly want to mess with the implementation as well.


Althoguh I think it is possible, it is uncommon to lock
files using CVS. I have never done it and haven't heard
from anyone doing it here.


I am not sure what you mean with CVS. When I say "lock" I am refering to a
source control system like SourceSafe, MKS or PVCS.


CVS, the version control system.
(www.cvshome.org)
After years of trouble with VSS, we
switched to CVS. I was not happy about
that decision back then (although I
wanted to get rid of VSS as soon as
possible). But I learned to like CVS.
You should lock both interface and implemantation to make sure no one else
will change the interface while you are working on the implementation. They
are one. I know that it is unlikely someone will, I was just making the
point that interface and implementation are logically one (we are still
talking source code for a class).
As I said, I never lock anything. If
anyone changed anything I was working
on, I merge this into my local version
(and test it) before I checkin the
file(s).
[...]
Suppose I have a class 'X', used in just
about every part of a big project. Now I
found a bug in 'X::f()' and need to fix
that. Why would I need to lock/change the
interface?
Just lock, not change.


Why would I need to lock the interface?
[...]
Joining interface and implementation in one file does not break the
interface when you update the implementation.
I don't know if C# prevents recompilation
of dependend modules if you change a module
without changing any declarations. Maybe it
does so.
However, with the interface/implementation
separated, you have a nice check to make
sure you didn't change anything accidentally,
as your implementation most often won't
compile if you did.
Martin.

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 #108
> > It is not the physical separation of interface and implementation that
makes
clients independent of a class's implementation, it is you not messing with
the interface that makes clients independent of the implementation.
So when you checkin a c# file that you
have changed without changing anything
of the interface, does everybody have
to recompile the dependend modules?
If they care for the update they may want to recompile. If they don't, they
will not recompile. I'm not sure I understand what you are worried about.
Why should I lock a header if I won't change it???
To make sure that once you check in your updated implementation and unlock
your interface, the result will be consistent. You will be sure the
interface that matches the implementation has not been changed.
CVS, the version control system.
(www.cvshome.org)
Are you dislectic by any change? Ah, CVS stands for "Concurrent Versions
System". What was so bad about Visual SourceSafe?
As I said, I never lock anything. If anyone changed anything I was working on, I merge this into my local version (and test it) before I checkin the file(s).

Oh, that's nice. Why not keep everything on your local machine and ship that
version once it is time to release?

You are proving my point. If you do lock the stuff that belongs together no
one can change anything while you're working on it.
Suppose I have a class 'X', used in just
about every part of a big project. Now I
found a bug in 'X::f()' and need to fix
that. Why would I need to lock/change the
interface?

Just lock, not change.

Why would I need to lock the interface?
I give up, you win.
I don't know if C# prevents recompilation
of dependend modules if you change a module
without changing any declarations. Maybe it
does so.


You seem awefully afraid of recompilation. Could you be working on this one
big monolithic application in which everything depends on everything for
which any change will cause a chain reaction in the C++ compiler, rendering
your machine useless for 20 minutes? Could it be someone influencial in your
company declared "Build All" the only way to compile and had the compile
option removed from all of your Visual Studio installations? I don't see the
problem, recompilation of one class should not be issue.

Martin.
Nov 15 '05 #109
> > It is not the physical separation of interface and implementation that
makes
clients independent of a class's implementation, it is you not messing with
the interface that makes clients independent of the implementation.
So when you checkin a c# file that you
have changed without changing anything
of the interface, does everybody have
to recompile the dependend modules?
If they care for the update they may want to recompile. If they don't, they
will not recompile. I'm not sure I understand what you are worried about.
Why should I lock a header if I won't change it???
To make sure that once you check in your updated implementation and unlock
your interface, the result will be consistent. You will be sure the
interface that matches the implementation has not been changed.
CVS, the version control system.
(www.cvshome.org)
Are you dislectic by any change? Ah, CVS stands for "Concurrent Versions
System". What was so bad about Visual SourceSafe?
As I said, I never lock anything. If anyone changed anything I was working on, I merge this into my local version (and test it) before I checkin the file(s).

Oh, that's nice. Why not keep everything on your local machine and ship that
version once it is time to release?

You are proving my point. If you do lock the stuff that belongs together no
one can change anything while you're working on it.
Suppose I have a class 'X', used in just
about every part of a big project. Now I
found a bug in 'X::f()' and need to fix
that. Why would I need to lock/change the
interface?

Just lock, not change.

Why would I need to lock the interface?
I give up, you win.
I don't know if C# prevents recompilation
of dependend modules if you change a module
without changing any declarations. Maybe it
does so.


You seem awefully afraid of recompilation. Could you be working on this one
big monolithic application in which everything depends on everything for
which any change will cause a chain reaction in the C++ compiler, rendering
your machine useless for 20 minutes? Could it be someone influencial in your
company declared "Build All" the only way to compile and had the compile
option removed from all of your Visual Studio installations? I don't see the
problem, recompilation of one class should not be issue.

Martin.
Nov 15 '05 #110

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
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...
0
5884
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4499
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4088
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

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.