Interface versus abstract class (in a specific case)

Question

I did a search on this website to avoid duplication, however most of the questions concerned an abstract comparison between an interface and an abstract class.

My question is more about my specific situation, especially my colleague, and I do not agree with the same approach.

I have 3 classes

• Node (Annotation node in the folder structure)
• Folder (contains subfolders and files)
• File

We use a composite template to get all the folders and their permissions for each user / group

Node class, should it be an interface or an abstract class? Folder and File inherit from Node.

In my opinion, I think that Node should be abstract, because File should not have all the methods that Folder has, for example, AddFolder(Node node)

My colleague said it’s better to use an interface for better coding.

Edit: I rewrote my node as follows:

 public abstract class Node { public string Name { get; set; } public string FullName { get; set; } public Node Parent { get; set; } public List<PermissionEntry> Permissions { get; set; } protected Node(string fullName) { FullName = fullName; Permissions = new List<PermissionEntry>(); } public void AssignPermission() { // some Codes } } 

Answer 1

There is no right answer. It really comes down to this question

"Is there any Node implementation that is common to File and Folder ?"

If so, you need an abstract class, not necessarily with an interface that describes its behavior

If the answer is no, you can make it an interface, optionally with an abstract base.

So you see - this is basically the same thing.

---

In addition, there is nothing stopping Folder adding additional methods not defined on Node that File would not share.

eg,

 public interface INode { void SomethingCommon(); } public File: INode { public void SomethingCommon(){...} // I must implement this } public Folder : INode { public void SomethingCommon(){...} // I must implement this public void AddFolder(string name) { // File doesnt need this method, its not on the interface! } } 

Answer 2

Your discussion of abandoning the interface seems to be off. Why did File have an AddFolder method if Node was an abstract class, but was it an interface?

Usually you create an abstract class if you have common functionality that all children share. In this case, this general functionality will be implemented by the abstract base class, therefore, it should not be implemented in all child elements.

In many cases, you even have both:

• Interface describing the contract
• An abstract class that implements an interface and some common functions

Answer 3

From what you say ....

Whether the Node is an interface or a class, if it has the "AddFolder" method, and File cannot implement it, then you have problems with the design.

The problem is that Node is not abstract enough, you need to narrow it down to a common interface.

Answer 4

Your argument for why Node should be abstract, because File should not have the same methods as Folder. Why does creating a Node interface imply that they will have the same methods? INode can be a marker interface that implements File and Folder. If the folder has a separate set of operations (which it does hopelessly), then I would have a different interface for this IFolder with the indicated operations.

From a short question, I personally would use the interfaces in this scenario, since using inheritance it was very easy to define something on Node so that the file inherits that does not belong to the file.

Answer 5

I usually use this rule:

If two classes have some common methods, but their implementation is different, use the interface.

If two classes have common methods and they use some common implementation, use an abstract class as a base class.