Abstract classes and interfaces in a game inventory system
I think your design introduces a few more dependencies than it should.

Let's have a look at your IUsable interface

public interface IUsable&lt;Player&gt; {
    void Use ( Player player );
}


Do you really need to have a dependency on Player? Why don't you just require it to depend on IUser?

I'd also completely get rid of the Item class. What do you need it for? If you want an abstract class to represent a NamedItem you can create it but you should do it in the following way:

public abstract class NamedItem implements IUsable&lt;IUser&gt;
{
    public string Name {get; private set;} // Better to keep it immutable

    protected NamedItem(string name)
    {
        Name = name;
    }

    public abstract void Use(IUser user);
    /*
     * This way we don't need to provide a 
     * default implementation and your subclasses
     * will be forced to provide it.
     */
}


I think you should probably also revise who should be in charge of implementing the Use method. From the names you're using it is quite clear that it is more natural to think at a player that uses an item. That's fine but what your code suggests is that different objects should be used in different ways, hence you need to implement it on the specific Item instance.

Does spreading the logic on how a player uses an item across a lot of different items makes sense in your project? If you don't want to do it you might want to have a look at dobule dispatch as a possible way to retain all the behaviours on player instead than on objects. If you do double dispatch you can have interfaces such as IFood and then have a method in Player with this signature void User(IFood food). IFood should expose a way to determine how many energy is added by the food to the player and the mutation of the state of the player should happen in the specific method you just created.

If you show us how you intend to use those classes we can help you find the best way to design them.