Initial Commit

- Welcome to the world.
Contract/Extensions Namespaces

- Moved contracts to their own ".Contracts" sub-namespace.
- Moved extension methods to their own ".ExtensionMethods" sub-namespace.
Application Layer Split

- This was a huge refactor to try and show some composition across layers. Components defined in the application layer can be composed of items defined in the layer below it (I want this to be the "data" layer, but I haven't actually named it properly yet).
- There looks to be a ton of duplicated code now, but I think the reality is I prematurely added a lot of collections for my data types, and I'm not even sure they're ever going to get used. Then they got duped to exist as collections for the new application layer types, which are completely incompatible because I didn't inherit here.
Namespace Renamed => Data Layer

- As per my previous commit, the initial layer *was* the data layer, but it wasn't named as such. I've gone ahead and updated the assembly names, the paths on disk, and the namespaces to reflect this.
Contract Cleanup

- Cleaning some various contract complaints from the IDE.
Contract Cleanup

- More contract cleanup... Not too many complaints from the analysis tool now.
Initial Work On Socketing

- My goals right now are to try and make an API I enjoy working with, so I'm trying out an API I think I'd like inside of the tests and then coding some of the backend. This means I might start coding in little hacks here and there (i.e. why did I make every item by default have 1 open socket?) but I'll have tests that I can tweak later to make sure the behaviour is as I expect.
- This commit is all about getting some of the basics for socketing items.
[WIP] Socketing

- As per my last commit message, I was able to clean up some of the internals for socketing. The total number of sockets is now an item stat.
[Items] [Socketing] Socketing Accumulates Weight

- Modified the socketing process to incorporate the weight of the socket candidate into the socketable item.
- Modified tests to prove this.
[Items] [Socketing] [Enchantments] Socketing Can Provide Enchantments

- Modified the socketing process to incorporate the enchantments of the socket candidate into the socketable item.
- Modified tests to prove this.
[Items] [Socketing] [Enchantments] Socket Enchntments Can Expire

- Enchantments provided by socket candidates to a socketable are capable of expiring now.
- Added a test to prove this.
[Items] [Socketing] Socketed Items From Data Layer

- The item class in the data layer will now instantiate a collection of items for the socketed items property.
- The item class in the application layer will now add in all of the necessary socketed items from the data layer object.
[Items] ItemType and MaterialType

- Added two properties that existed in my old design for what should be included as part of items. Examples of how these can get used include:
-- Using the material type as a resource ID to later have the app layer create a material object, and then have skills dependent on things like a Bone material being used.
-- Using the item type as a resource ID to later have the app layer create an item type object, and then have skills require things like "doesn't work with swords, but works with maces".
[Items] [Stats] Item Stats Stored In Collection

- Instead of storing a cache of each calculated stat in an item as it's own variable, leverage the stats collection.
- Added a GetStat() method that would allow callers to look up any type of stat they want on an item.
[Items] [Materials] Builder, Factory and Complex Immutable Construction!

- This commit has some interesting pattern usage, and I'm not even sure I'm comfortable with it yet. Let me start by saying that my item class is going to get pretty complex in terms of what it's composed of, and since I want to keep a lot of the properties get-only, it makes it tricky to get all of that information into the class.
- This commit also added an IMaterial that I hinted at in a previous commit... This is just an easy way to start tackling a problem I think is going to get really nasty later on when I start adding more and more to the item class (which, of course, I need to keep an eye on in terms of complexity).
- I decided that I'd implement a builder pattern (and because I'm trying to take programming to interfaces to an extreme here, if you haven't noticed) I have an interface on this too.
-- A caller would say Item.Builder.Create() to get a new IItemBuilder instance.
-- The caller can use this new instance to assign their necessary resource loaders, so in this case, WithMaterialFactory().
-- The caller can finally say Build() with some parameters that will be specific to the new item instance.
--- NOTE: I played around with how I felt about the IEnchantmentCalculator... this thing will eventually have scope about the game world (i.e time of day, weather, current map, players, etc...) and I'm still undecided as to whether I want to associate it with the builder, or with the instance of the item I'm making... So I left it where it was. Easy enough to change later, I think.
-- The builder itself is passed into the constructor of the item (mind blowing, right?) so that it can access the factories to help load up the resources it needs.
- Few of my concerns/thoughts right now:
-- Not sure how I feel about that whole design... I've never done something like this before, but it actually seemed to work pretty well.
-- Need to nail down naming...
--- I use Create() to make an item instance to meet an interface
--- My only factory used Load() to map an ID to an interface instance.
--- I use Build() on my only builder to make a new instance after everything is set properly.
--- Should I follow this trend? Are some of these actually the same thing?
Create README.md
[Items] [Enchantments] EnchantBlock Is INotifyCollectionChanged

- Made the EnchantBlock class leverage INotifyCollectionChanged so that any modification to the collection can be listened to. This means the Item class can now listen for the event to set the dirty stats flag.
- Added contract for IItemBuilder (and pulled that sucker to its own file).
- Tweaked contract settings to try being  bit more strict.  I think sometimes it fails builds... but only AFTER it builds? It's kind of weird, but I'm still experimenting. I'm learning that I need more contracts!
[Contracts] A Contract For You! And You! And You!

- Playing around with the static analysis... Figuring out that I can add more and more contracts. Definitely an iceberg type of thing going on.
[Contracts] More Contracts...

- Learning that adding code and ensuring all the contracts can be a ton of work.
[Contracts] Contract.Ensure

- I figured something was up early on, but I didn't quite grasp it. My getters on my contract classes where doing a Contract.Requires instead of Contract.Ensures. I cleaned all of these up now.