Lvl 1 upgradeable attributes

I've built the groundwork for an attributes (as in Strength, Intelligence, not as in DebuggerHidden, TestMethod) framework for my game. Each attribute can be upgraded and downgraded individually as well as part of a bulk change (such as for upgrades that have side effects, or leveling up).

I'm looking to get a thorough critique of the groundwork before I go expanding on shaky foundations.

UpgradeableStat and UpgradeableStat

These are the absolute bases of the attributes system. UpgradeableStat only really exists so as to allow me to hold a collection of UpgradeableStat instances with different T types, all attributes will really extend from UpgradeableStat

public abstract class UpgradeableStat
{
    public abstract void Upgrade();

    public abstract void Downgrade();
}

public abstract class UpgradeableStat : UpgradeableStat
{
    public abstract T Value
    {
        get;
    }
}

OneShotStat

These attributes will be applied once, until it's been removed (whereby it's applied again). Think of it as a door, you can't open it again unless it's been closed.

```
///
/// A statistic that is upgraded only once until it is next removed.
///
public class OneShotStat : UpgradeableStat
{
///
/// Gets the value.
///
///
/// The value.
///
public override T Value
{
get
{
return Upgraded ? UpgradedValue : DowngradedValue;
}
}

///
/// Gets or sets the upgraded value.
///
///
/// The upgraded value.
///
public T UpgradedValue
{
get;
set;
}

///
/// Gets or sets the downgraded value.
///
///
/// The downgraded value.
///
public T DowngradedValue
{
get;
set;
}

///
/// Gets a value indicating whether this is upgraded.
///
///
/// true if upgraded; otherwise, false.
///
public bool Upgraded
{
get;
private set;

Auto-properties are convenient, because they let you declare properties in a compact form. This defeats the purpose:

public T UpgradedValue
{
    get;
    set;
}

Should be a simple one-liner:

public T UpgradedValue { get; set; }

Same here:

public abstract T Value
{
    get;
}

Get-only abstract properties are easily eye-parsed as a one-liner, too:

public abstract T Value { get; }

@BrunoCosta already mentioned it, but I can't help mentioning it too:

/// 
/// Gets the value.
/// 
/// 
/// The value.
/// 

Ugh. XML comments like this bring nothing to the table and do nothing other than cluttering up the code. Remove them, be merciless :)

XML comments only make sense for public members. This one is useless, on top of being redundant:

/// 
/// The level
/// 
private int level;

Picture XML comments as documentation - you can export them and build an actual help file, or MSDN-like documentation for your API; if all they do is state the obvious, you'll have a very frustrating documentation! Make comments useful, or remove them.

StackExchange Code Review Q#77609, answer score: 11