When you need a part of the class to be implemented. The best example I've used is the template method pattern.
public abstract class SomethingDoer
{
public void Do()
{
this.DoThis();
this.DoThat();
}
protected abstract void DoThis();
protected abstract void DoThat();
}
Thus, you can define the steps that will be taken when Do() is called, without knowing the specifics of how they will be implemented. Deriving classes must implement the abstract methods, but not the Do() method.
Extensions methods don't necessarily satisfy the "must be a part of the class" part of the equation. Additionally, iirc, extension methods cannot (appear to) be anything but public in scope.
edit
The question is more interesting than I had originally given credit for. Upon further examination, Jon Skeet answered a question like this on SO in favour of using interfaces + extension methods. Also, a potential downside is using reflection against an object hierarchy designed in this way.
Personally, I am having trouble seeing the benefit of altering a currently common practice, but also see few to no downsides in doing it.
It should be noted that it is possible to program this way in many languages via Utility classes. Extensions just provide the syntactic sugar to make the methods look like they belong to the class.
[1] Add virtual "getters" & "setters" to your properties, I had to hack another control library, because I need this feature:
abstract class Control
{
// internal fields for properties
protected int _Width;
protected int _Height;
protected int _BackColor;
protected int _X;
protected int _Y;
protected bool Visible;
protected int BorderWidth;
protected int BorderColor;
// getters & setters virtual !!!
public virtual int getWidth(...) { ... }
public virtual void setWidth(...) { ... }
public virtual int getHeight(...) { ... }
public virtual void setHeight(...) { ... }
public virtual int getBackColor(...) { ... }
public virtual void setBackColor(...) { ... }
public virtual int getX(...) { ... }
public virtual void setX(...) { ... }
public virtual int getY(...) { ... }
public virtual void setY(...) { ... }
public virtual int getBorderWidth(...) { ... }
public virtual void setBorderWidth(...) { ... }
public virtual int getBorderColor(...) { ... }
public virtual void setBorderColor(...) { ... }
public virtual bool getVisible(...) { ... }
public virtual void setVisible(...) { ... }
// properties WITH virtual getters & setters
public int Width { get getWidth(); set setWidth(value); }
public int Height { get getHeight(); set setHeight(value); }
public int BackColor { get getBackColor(); set setBackColor(value); }
public int X { get getX(); set setX(value); }
public int Y { get getY(); set setY(value); }
public int BorderWidth { get getBorderWidth(); set setBorderWidth(value); }
public int BorderColor { get getBorderColor(); set setBorderColor(value); }
public bool Visible { get getVisible(); set setVisible(value); }
// other methods
public Rectangle ClipRectange { get; protected set; }
abstract public void Draw();
} // class Control
/* concrete */ class MyControl: Control
{
public override bool getVisible(...) { ... }
public override void setVisible(...) { ... }
} // class MyControl: Control
I know this suggestion is more "verbose" or complex, but, its very useful in real world.
[2] Add an "IsEnabled" property, do not confuse with "IsReadOnly":
abstract class Control
{
// internal fields for properties
protected bool _IsEnabled;
public virtual bool getIsEnabled(...) { ... }
public virtual void setIsEnabled(...) { ... }
public bool IsEnabled{ get getIsEnabled(); set setIsEnabled(value); }
} // class Control
Means you may have to show your control, but don't show any information.
[3] Add a "IsReadOnly" property, do not confuse with "IsEnabled":
abstract class Control
{
// internal fields for properties
protected bool _IsReadOnly;
public virtual bool getIsReadOnly(...) { ... }
public virtual void setIsReadOnly(...) { ... }
public bool IsReadOnly{ get getIsReadOnly(); set setIsReadOnly(value); }
} // class Control
That means the control can display information, but cannot be changed by the user.
Best Answer
Simple answer to your question : No, your friend is wrong.
An interface provides no implementation of the methods it defines. Would it make sense if we could instantiate one of those? Of course not. Interfaces are only that, an abstraction.
This is obviously assuming that when you say
interface
, you think about the interface language feature as defined by C#, Java, C++, etc with theinterface
keyword. In the case your friend means an API interface, then the question does not really make sense to me. APIs may allow you to extend functionality through subclassing or by adhering to a particular contract as defined by an interface or an existing class of the system.