It usually depends on what the statagey is for, and how much implementation you need to share. A class can inherit from (implement) multiple interfaces, but only inherit one class which could be abstract.
An interface is the method definitions only, where an abstract class can contain some default implementation. Each implementer of an interface could do things completely different. For example imagine an ISort interface, each implementor would use different fields within the class to determine how the class is sorted, so it doesn't really make sense to have implementation. Abstract classes can be really useful, I've used one recently that really works, it's based on the GoF template method design pattern. It allows you to define the steps of an algoritom, for which each step calls a method, some of these methods are abstract, and provide default implementation for some of them, the class wouldn't be any use directly, but it's subclasses are of great use because they conform to the interface of the abstract class, and can hence be used interchangeably. Duncan ----- Original Message ----- From: "Steven Fraser" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, April 19, 2002 9:06 AM Subject: [DOTNET] Abstract classes > What is the difference between using an abstract class and using an > interface class? If I'm designing a strategy pattern why does the strategy > class have to be abstract and not an interface class. > > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
