Lvl2 upgradeable attributes

This is a follow up to:

• Lvl 1 upgradeable attributes

From before:


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.

I've made a full overhaul following the community's recommendations of my attributes system. I have kept the doc-level comments, because I intend to release this eventually with generated documentation, but I've made an effort to make the documentation more useful and detailed (of course, you will be the judge of that).

IAttribute

This is the basis for all attributes. It doesn't define much, simply that anything implementing this interface is an attribute and has a value of type T.

/// 
/// Interface for all game attributes, modifiable or not.
/// 
/// The type of the attribute's value.
public interface IAttribute
{
    /// 
    /// Gets the value of this attribute. This is the final, post-modification value.
    /// 
    /// 
    /// The value.
    /// 
    T Value
    {
        get;
    }
}

Attribute

Base concrete class for attributes. It has a fixed value that is set at construction. With the existence of this class, I'm not certain I need the IAttribute at all, but have kept it there to keep my options open later (in case I need an attribute for which a base value does not make sense).

```
///
/// An attribute with a base value.
///
/// The attribute's value type.
public class Attribute : IAttribute
{
///
/// Gets the value of this attribute
///
///
/// Unless overridden, this value is identical to the base value provided in the constructor.
///
///
/// The base value provided in the constructor.
///
public virtual T Va

I like the architecture - it looks sensible, flexible and extensible so kudos for that. There's not really much to criticise with the code either - it's clean and readable. I do wonder what benefit you get with the generics particularly if you're expecting numbers that could reasonably be dealt with using float the whole way down.

I also think you should initialise the Modifiers property to an empty list in the constructor for ModifiedAttribute.

The only real concern I have, which may or may not be valid, is the order of applying the modifiers. At the moment it's a first in, first executed model. This means that adding the same modifiers to the attribute in a different order result in a different value.

Say I have a defence attribute and I can modify it by putting on some armour (+5) and/or by drinking some special purple liquid (2). If the base level is 2, depending on which thing I do first, I can end up with a modified value of either 14 ((2+5)2) or 9 ((2*2)+5). Is that desirable, or should you have a more advanced ordering - e.g. additions always come before multiplications?

StackExchange Code Review Q#78232, answer score: 6