Tag: public

In the 2000s, a colleague told me that it was an anti-pattern to make public methods virtual or abstract.

For example, he considered a class like this not well designed:

public abstract class PublicAbstractOrVirtual
{
  public abstract void Method1(string argument);

  public virtual void Method2(string argument)
  {
    if (argument == null) throw new ArgumentNullException(nameof(argument));
    // default implementation
  }
}

He said that

• the developer of a derived class that implements Method1 and overrides Method2 must repeat the argument validation.
• if the developer of the base class decides to add something to the customizable part of Method1 or Method2 later he can not do it.

Instead, my colleague suggested this approach:

public abstract class ProtectedAbstractOrVirtual
{
  public void Method1(string argument)
  {
    if (argument == null) throw new ArgumentNullException(nameof(argument));
    this.Method1Core(argument);
  }

  public void Method2(string argument)
  {
    if (argument == null) throw new ArgumentNullException(nameof(argument));
    this.Method2Core(argument);
  }

  protected abstract void Method1Core(string argument);

  protected virtual void Method2Core(string argument)
  {
    // default implementation
  }
}

He told me that making public methods (or properties) virtual or abstract is just as bad as making fields public. If you include fields in properties, you can later intercept access to these fields as needed. The same applies to public virtual / abstract members: pack them as shown in the picture ProtectedAbstractOrVirtual With class the base class developer can intercept all calls of the virtual / abstract methods.

But I do not see that as a design policy. Even Microsoft does not follow this: look at that Stream Class to check this.

What do you think of this policy? Does it make any sense or do you think it overcomplicates the API?