https://github.com/alvarogarcia7/gilded-rose-kata-java
Practicing the Gilded Rose kata in java
https://github.com/alvarogarcia7/gilded-rose-kata-java
analogy architect atdd emily-bache gildedrose golden-master java kata legacy legacy-code make makefile maven mvn refactoring refactoring-exercise refactoring-kata technical-notes travis-ci ubiquitous-language
Last synced: 4 months ago
JSON representation
Practicing the Gilded Rose kata in java
- Host: GitHub
- URL: https://github.com/alvarogarcia7/gilded-rose-kata-java
- Owner: alvarogarcia7
- Created: 2017-07-29T09:59:41.000Z (almost 8 years ago)
- Default Branch: master
- Last Pushed: 2017-08-04T12:56:01.000Z (almost 8 years ago)
- Last Synced: 2025-01-10T22:49:47.236Z (6 months ago)
- Topics: analogy, architect, atdd, emily-bache, gildedrose, golden-master, java, kata, legacy, legacy-code, make, makefile, maven, mvn, refactoring, refactoring-exercise, refactoring-kata, technical-notes, travis-ci, ubiquitous-language
- Language: Java
- Homepage:
- Size: 82 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Gilded Rose kata
Practicing [Emily Bache][emilybache]'s [Gilded Rose][gildedrose] 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 `Rule`s 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 `Item`s 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
[gildedrose]: https://github.com/emilybache/GildedRose-Refactoring-Kata/tree/master/Java
[emilybache]: https://github.com/emilybache