You're thinking about it wrong. Whether you use an interface or an abstract class should be a decision you make when creating the entity. Later on, when you're deciding to construct it you would use an abstract factory pattern.
They were just merely showing that it can handle either form of abstraction. An interface is generally viewed as "better" since it allows looser coupling by not forcing a constructor and not using up your inheritance link. However, it is also rarer to use a factory to return an interface, since usually you want to give people the ability to inject their own implementation of interfaces, which is not traditionally a role of the factory pattern (though it certainly can be)
There is one specific benefit to using interfaces that I can think of; you can implement two different interfaces with the same class. Here is a (fairly stupid) example:
interface IProvideInfo {
string Get();
}
interface IProvideConnectionString : IProvideInfo { }
interface IProvideCurrentUserName : IProvideInfo { }
class CurrentContextProvider : IProvideConnectionString, IProvideCurrentUserName {
string IProvideConnectionString.Get() {
return ConfigurationManager.ConnectionStrings["db"];
}
string IProvideCurrentUserName.Get() {
return _currentUserName;
}
string _currentUserName;
public string SetCurrentUserName(string s) {
_currerntUserName = s;
}
}
public class InfoProviderFactory {
CurrentContextProvider _provider = new CurrentContextProvider()
public IProvideInfo GetProvider(string key) {
return _provider;
}
}