OO question on overriding virtual methods

[ORi]

Hi all !

There's a question I've been bothering for a while:

I'm actually developing architectural frameworks for application
developing and I think virtual methods, although needed because of the
flexibility they introduce (flexibility really needed in framework
developing), are often a nuisance for final developers. They don't
like them because they never know if base class must be called and
where should they place the call if needed, so we have mostly two
different situations:

1) Base method should always be called !! : We've solved this issue by
using Template Methods, this way it doesn't matter if the class calls
base method or not.

2) Method can be overriten if needed but if it is, base method should
NOT be called. A silly example might be the following:

public class A
{
private int _att;

public virtual void foo()
{
_att = 5;
}
}

public class B:A
{
public override void foo()
{
//here they might need to alter _att's value so base.foo() should
//never be called after their code.
_att = 6;
}
}

This is specially a problem since we've changed to VS.Net 2003 and the
IDE automatically creates override sentences and inserts the base
method call which is what I want to avoid.
I can't find a way to achieve this, and any help would be appreciated
!!

thx in advance
ori

[Frans Bouma [C# MVP]]

ORi wrote:

There's a question I've been bothering for a while:

I'm actually developing architectural frameworks for application
developing and I think virtual methods, although needed because of the
flexibility they introduce (flexibility really needed in framework
developing), are often a nuisance for final developers. They don't
like them because they never know if base class must be called and
where should they place the call if needed, so we have mostly two
different situations:

1) Base method should always be called !! : We've solved this issue by
using Template Methods, this way it doesn't matter if the class calls
base method or not.

2) Method can be overriten if needed but if it is, base method should
NOT be called. A silly example might be the following:

public class A
{
private int _att;

public virtual void foo()
{
_att = 5;
}
}

public class B:A
{
public override void foo()
{
//here they might need to alter _att's value so base.foo() should
//never be called after their code.
_att = 6;
}
}

This is specially a problem since we've changed to VS.Net 2003 and the
IDE automatically creates override sentences and inserts the base
method call which is what I want to avoid.
I can't find a way to achieve this, and any help would be appreciated
!!

I'm a little confused what you're asking, because in B, _att is not
accessable, so _att=6 is not compilable.

FB
--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[ORi]

It's a mistake, obviously _att should be protected so that could be
modified within B class.

The point is that A has a method that alters some of his attribute's
state, this method may be overriden in B to change this behaviour but
then the call to A foo() method should not be allowed

thx !
ori

public class A
{
private int _att;

public virtual void foo()
{
_att = 5;
}
}

public class B:A
{
public override void foo()
{
//here they might need to alter _att's value so base.foo() should
//never be called after their code.
_att = 6;
}
}

[Kjetil Bjerknes]

> I'm actually developing architectural frameworks for application

developing and I think virtual methods, although needed because of the
flexibility they introduce (flexibility really needed in framework
developing), are often a nuisance for final developers. They don't
like them because they never know if base class must be called and
where should they place the call if needed, so we have mostly two
different situations:
Im my opinion this boils down to one thing: Documentation. If you
document the methods in a way that clearly states what it does, and
what return values it has, then it should be no problem overriding the
method. If you understand how the method is supposed to work when
called directly on the base class, then why don't you understand how
it works when called from a sub-class?

I actually think it's more annoying when the developer of a base class
choose not to mark a method as virtual, because it limits severly what
I can do in my sub-class.

1) Base method should always be called !! : We've solved this issue by
using Template Methods, this way it doesn't matter if the class calls
base method or not.
I don't think it's a good idea to create a general rule like this, but
if you're unsure what the base method does (caused by bad
documentation/design :), you can't go much wrong by calling the base
method as the first instruction. Any code following the base call will
simply extend or replace the behaviour of the base method.

2) Method can be overriten if needed but if it is, base method should
NOT be called. A silly example might be the following:

public class A
{
private int _att;

public virtual void foo()
{
_att = 5;
}
}

public class B:A
{
public override void foo()
{
//here they might need to alter _att's value so base.foo() should
//never be called after their code.
_att = 6;
}
}

You should avoid declaring fields as protected (I suppose you meant to
declare _att as protected and not private or else the example will not
compile). Ensure that your classes is properly encapsulated, which
means that only methods/properties are accessible from subclasses.
</KB>

[ORi]

[e-mail] (Kjetil Bjerknes) wrote in message news:<1f**************************@posting.google. com>...

Im my opinion this boils down to one thing: Documentation. If you
document the methods in a way that clearly states what it does, and
what return values it has, then it should be no problem overriding the
method. If you understand how the method is supposed to work when
called directly on the base class, then why don't you understand how
it works when called from a sub-class?

I actually think it's more annoying when the developer of a base class
choose not to mark a method as virtual, because it limits severly what
I can do in my sub-class.
Yep, we already have a dozen of fantastic books documenting our
different frameworks and I'm still waiting the day when somebody will
ask me for them :) Actually we have lessons for learning how to use
the tools and everybody is supposed to be an expert with them.

In reality, life isn't so easy... While I agree that a good
documentation is very important, in large developments involving lots
of teams and different people with different skills using the same
tools you can't trust that they all will know how to use them
properly, even with all the documentation available since most of them
will never read it :)

In that kind of projects I think it's necessary to limit what they are
able to subclass or redesign in the framework, specially when talking
about frameworks, whose one of their first intentions is to unify
development process in all the company so a high degree of flexibility
in their development should be avoided.

However, I agree with you that in reduced teams, you should promote
flexibility and support it in a good documentation. I also think that
the best way to document an application is the code itself

I don't think it's a good idea to create a general rule like this, but
if you're unsure what the base method does (caused by bad
documentation/design :), you can't go much wrong by calling the base
method as the first instruction. Any code following the base call will
simply extend or replace the behaviour of the base method.
Not a general rule, the opposite. The problem is where overriding is
used in a situation where Template Method pattern should have. That is
when you have some code in a base class that has to be mandatory
executed but child classes can extend it at some point. I think it's
an error to implement it using virtual methods and expecting that the
child will call base method (even with good documentation) and should
be do it with a template. This is what I was trying to point !
You should avoid declaring fields as protected (I suppose you meant to
declare _att as protected and not private or else the example will not
compile). Ensure that your classes is properly encapsulated, which
means that only methods/properties are accessible from subclasses.

The point was not on data encapsulation or direct variable access !
Maybe the code was a bit confusing, it's intent was to ilustrate a
situation where a overriden method should not call it's base method if
overriden. I just thought a small example could help :) the discussion
on data encapsulation is beyond what I intended to expose in this
thread

Thx for all :)
ori