Inheritance: Folders and Files & Liskov Substitution Principle

Question

Based on what I have been reading about the Liskov Substitution Principle, I understand that a square and rectangle class cannot be a part of the same inheritance tree.

I would like to apply these ideas to a Folder and a File, as they commonly exist on disk. Is there a property of one or the other or both which would force a conclusion they too should not be part of the same inheritance tree according to Liskov?

What are some properties we could consider?

1. The data. Files consist of bytes. However, Folders can be considered to consist of the bytes of the files they contain.

2. Access to both is defined by permissions

I suppose the property where inheritance breaks down would be one concerning containment. A folder contains files. A file does not. However, if one considers that a file is just a collection of bytes, then a folder could be considered to be just the collection of bytes consisting of the files in the folder.

Is there a property of a file or a folder that requires us to maintain two inheritance trees?

Answer 1

The "substitution" from LSP does not mean that the subclass ultimately behaves same as way the super class. It cannot do it always anyway, simply because it is another class.

What it does mean is that the contract which is important to the code it is being injected to does not change. So, for the Folder and File there are a lot of common:

• Both have parent directory
• Both have name
• Both may exist of not
• Both have permissions and ownership
• Both can be moved, copied to another directory
• Both can be renamed
• Both can be deleted

So for a code which only uses the properties and methods, you could substitute one with the other without violating the LSP.

The data. Files consist of bytes. However, Folders can be considered to consist of the bytes of the files they contain.

This is rather unorthodox, I believe it would not be reasonable to do so. Though I remember in some Unix-like OS I could read a directory as a text file which were listing files.

Answer 2

If you are creative enough you can make one descend from the other and satisfy Liskov. But you would have to bend semantics, like with square and rectangle. And that would not benefit your model or make it easy to work with by folks who have a good understanding of what a square, a rectangle, a file or a folder is.

You could argue that a square is a simple rectangle that has 4 sides with just one side length specification x. Then rectangle could descend from it and have an additional side length specification y. Then if you treated a rectangle like a square you would be OK. Whenever you draw it you would just use x for all four sides and that would make a square.

But that would be a technical trick to make ends meet without making much sense and it is the same with files and folders. If you take meaning of properties into account (rather than just treating them as variables that may have different meaning depending on the context), this would fall apart. A good model is serious about semantics, if it is not it will be a pain to work with. So whatever the answer to your question is, you should not be smart just to fix something that does not fit naturally.