Interfaces and Abstract Classes. And why not?
Been teaching more programming. Today we did (amongst other things) interfaces and abstract classes. People have problems with these. Here my technique. There are just two things you need to remember here:
Product is a great name for an abstract class.
IDoEdit is a great name for an iterface.
If you can get these two lines into your head you can figure out everything else from scratch. Abstract classes serve as templates for the "real" classes underneath them. You'll never make an instance of a class called Product. You might make an instance of a class called ToothBrush, or BusStop, but you'll never make one called Product.
IDoEdit is something that any class can do. If they implement the IDoEdit interface they can be asked to do the edit thing. And a class which implements the IDoEdit interface can be thought of purely in terms of this ability and nothing else. The C# convention is to put an I in front of interface names.
So if you remember that the one that begins with I (and contains I too) is the interface and the other one is Product, you will do fine. I'm a great believer in getting the context of the thing sorted so that you can "figure out" what it does, rather than trying to remember a bunch of stuff.