Gilded Rose kata

Practicing Emily Bache's Gilded Rose kata

Technical notes

This is the process used to reach the current state:

• I've created a golden master testing strategy for the existing features
• Break the dependencies to GildedRose, pushing behavior down to the newly-created objects
• Follow TDD to add the new feature (Conjured Item support)
• Do not add more unit test coverage, as there is no request for further user stories/business features*

Protecting the Item

As the Item class cannot be modified, I've created a wrapper to push the behavior to the new class.

Separating the rules

In the current solution, the behavior related to updating quality lives in the domain.Item class and its children.

This can be seen as a Rule and a Rule Engine pattern: the domain.Item (plus children) are the Rules and the Factory::build is the Rule Engine

Each rule is autonomous on how to apply itself. The rule itself indicates whether there is a match or not (using an Option). The rule engine just iterates through them until a match is found. Therefore, the order of the rules matters

Using factories

Using factories (or named constructors) instead of normal constructors has been a great success.

By contract, the constructor MUST return an instance of the class, but a named constructor MUST return an instance of the class or any children (covariant)

Project as a legacy codebase

I've decided to handle this refactoring kata as a legacy codebase and do not add unit tests for the existing behavior.

For the new behavior, on the other hand, it's now easy to create unit tests, follows a request from business to expand the behavior, so I've added unit tests

Ubiquituous language

The ItemProductionCenter is where Items are produced

The role of the Architect

I've tried to find abstractions for those who decide when to build: Architect. They decide when a Builder pattern should be used