The problem with your friend's simplification is that determining whether or not a method will ever need to change is exceptionally difficult. It is better to use a rule that speaks to the mentality behind superclasses and interfaces.

Instead of figuring out what you should to by looking to what you think the functionality is, look to the hierarchy you are trying to create.

Here is how a professor of mine taught the difference:

Superclasses should be is a and interfaces are acts like or is. So a dog is a mammal and acts like an eater. This would tell us that mammal should be a class and eater should be an interface. An example of is would be The cake is eatable or The book is writable (making both eatable and writable interfaces).

Using a methodology like this is reasonably simple and easy, and causes you to code to the structure and concepts rather than to what you think the code will do. This makes maintenance easier, the code more readable, and the design simpler to create.

Regardless of what the the code might actually say, if you use a method like this you could come back five years from now and use the same method to retrace your steps and easily figure out how your program was designed and how it interacts.

Just my two cents.

The problem with your friend's simplification is that determining whether or not a method will ever need to change is exceptionally difficult. It is better to use a rule that speaks to the mentality behind superclasses and interfaces.

Instead of figuring out what you should do by looking to what you think the functionality is, look to the hierarchy you are trying to create.

Here is how a professor of mine taught the difference:

Superclasses should be is a and interfaces are acts like or is. So a dog is a mammal and acts like an eater. This would tell us that mammal should be a class and eater should be an interface. An example of is would be The cake is eatable or The book is writable (making both eatable and writable interfaces).

Using a methodology like this is reasonably simple and easy, and causes you to code to the structure and concepts rather than to what you think the code will do. This makes maintenance easier, the code more readable, and the design simpler to create.

Regardless of what the the code might actually say, if you use a method like this you could come back five years from now and use the same method to retrace your steps and easily figure out how your program was designed and how it interacts.

Just my two cents.