This post is absolutely a "I don't have a post" filler post.
I'm working on a couple of refactoring "kata" type projects. One is for MicroObejct technical practices.
I'm trying to do them all as "FizzBuzz" but... I'm kinda struggling for some of them. FizzBuzz doesn't have nulls... How the hell do I create a refactor kata for removing nulls...
There's some challenges for that. I have some ideas. Clearly I can't do the standard FizzBuzz.
I think part of my problem is that I'm trying to do them in "Technical Practices" order. No Nulls comes before No Primitives. But I might need an abomination of the no primitives to refactor No Nulls... I don't know. that's a huge part of the struggle I'm facing developing these. I don't know the best code to demonstrate the technical practice.
It's something I want to provide to ... well.. I want to provide it to you. The goal is to help you learn the practices I'm advocating. I need some code for you to practice them on. I'm working on it... and struggling at getting small samples that enable actually applying the practices.
Greenfield is nice... but my greenfield simply... does them. We don't get to see the change in code. I think being able to see the code transformation is crucial to understanding why we should apply these practices. We're not going to see why if we can't see why it improves.
It's slow going... I have No Getters, No Setters, If Only As Guard Clause, and Isolate Their Code.
It's public on my github, feel free to find it. :)
The other one I'm working on is a crap tastic version of my previous pizza shop.
I'm doing it very akin to how I would have before my new found understanding of object-oriented programming.
I started this hoping it'd be a good code sample to use for the MicroObjects technical practices kata.
It might work for that. I'm not sure. I'm not intentionally setting it up for all of the rules. I think "Isolate Their Code" will be a challenge with how simplistic it is. I mean, sure; I can fake file access... I might update it to that to have that example. Probably depends on how well the rest of the practices will apply...
Since I'm writing this... I'm gonna do a quick spot check
- No Getters/No Setters - Check
- Be Immutable - Check
- Interface Everything - Check
- Isolate Their Code - Nope
- No Public Statics - Check
- If Only as Guard Clause - Check
- Switch and else evil - check
- No Nulls - Ish
- No new inline - Nope
- Extract Cohesion - Maybe
- Composition over Inheritance - maybe
- No Primitives - Check
- No Enums - Check
- No logic in ctors - Nope
Three lacking isn't bad.
Some updating to get values from a file/json will give me isolation.
I don't have any new's inline. Though making some kinda data store will probably bring those in.
Extracting cohesion is a maybe, but I think there will be at least a little for that.... It might just fall out from applying the rest of the practices.
My constructors are pretty empty - I don't think there exists a good class to demonstrate that chagne.
There's not a lot of nulls... it's ish. I can get rid of them; but it's not going to demonstrate the power the practice really has. I don't think it'll get to null objects. We don't have "null toppings"
I'd like a single example for everything... Maybe I can, maybe I can't... I mean... I CAN.
I want it as straight forward as possible though. Too much code and the transformation of the practices isn't going to be felt as strongly. At least other than No Getters.
No Getters simplifies by hiding the complexity in the class. The rest of the practices simplify inside the class.
I expect that I'll have quite a few attempts at developing code samples to practice the practices on. I'd love to help everyone one on one, but ... You're probably far far away from me so it won't work out so well.
I'll continue to explore ways I can help others learn what I've discovered helps me.