The Pizza Shop

The Start
More µObjects
New Requirements
Calzoned
The Final

I started the Pizza Shop example to show how to apply µObjects in code; Using a very similar process I do in production code.
From there, working through the changes and applying them. Originally I hoped to show how µObjects handles the challenges presented in the changing requirements - but that's not quite where I ended up with.
I realized that the Pizza Shop practice is around how Objects simplify making changes. µObjects are extremely small objects. The µObjects Pizza Shop shows the simplicity that µObejcts allow easy refactoring.

All In A Week

I didn't start the pizza shop expecting to post it all in a single week - but ... I have so many µObject post ideas and in the works... I didn't want to push them back for this example. I also want this example out. There were no good code examples of µObjects - Now there's one; and it's complete.

Immutabiltiy

One experiment I did with this example was on Immutability. I decided to take an extreme form of immutability that state never changes.
A lesser form that I use at work is the references never change. Which is an acceptable form of Immutability, but not as strict as possible.

With the style of immutability use in the pizza shop has no changes to the data of the class. The prime example of this is adding a topping. A whole new pizza is created. With all new toppings. The previous pizza is unchanged.
Why do we do this? Because we want immutability. We don't want changes to affect what other people might be holding.

I have some tests that show if I return a new pizza with out a new toppings, both pizzas have the new topping. Same with changing the pizza type. If I change the pizza type, the old pizza would still get toppings added.

We could just add to the list, no new pizza. Then we know that the pizza state is changing. The list of toppings is changing inside that pizza. That's not immutability... not strict immutability.

I don't use this style at work; but I'll be starting to use it on all my own projects. I think it's provides stronger safety and guarantees in the code. Less unexplained and hard to reproduce bugs.

I think this style of immutability is harder to jump into. I expect exceptions to arise around book ends; but I don't know yet. This type of immutability is like async/await - It zombies through the code. EVERYTHING must follow strict immutability, or nothing really does.

TDD

I didn't do this as strict TDD, by the book, following uncle bob's three rules. I feel µObjects gives a small amount of variance to that. I don't know EXACTLY how to define this variance yet.
One of the things I say about TDD is that the tests are the least important part. The tests help drive the code into a maintainable state. Applying the "rules" of µObjects also force the code into a maintainable state.
TDD doesn't force short methods. You can do A LOT in a method and still follow TDD and the 3 rules. It's not the tests that get the code into objects with a single job; it's a mindset.
If you have the TDD mindset; you write tests for small amounts of code. What if you write small amounts of code then a test for it? If you have the correct mindset; whatever - it results in the same style of production code.
With µObjects - Everything is small. You can't get away from the small bits of code. That IS µObjects.
I have a theory that µObjects gets devs to write code in VERY similar fashions... there's not a lot of ways you can write "A THING". This similarity is huge for maintainability. It's simple to test. It's simple to change.
A lot like microServices - if you need to make a change, just write a new one. It's small enough.
It's a theory I have about using µObejects... that test first isn't as important to drive the code into a SOLID and CLEAN state for high maintainability.

Refactoring

Just µObjects isn't fully enough to get the ease shown in this example. A huge part is the TDD cycle. Red-Green-Refactor. The refactor step is huge. There was a lot of refactoring done through the example posts. In the last one, the refactoring allowed us to delete a lot of classes. These refactors keep the code clean. Clean code is maintainable code - The best kind of code.
The entire second post More µObjects is refactoring the code. That's how important I think refactoring is to good µObjects code. 20% of the posts are DEDICATED to refactoring.
This is an amusing number to me; as we spend about a day a week just refactoring. It simplifies what we do next an amazing amount. We refactor into common patterns and styles. When we need to add something new; we have how to do it; and a solid base to build on top of.
We added image responses; took a couple new classes integrated with the rest of our existing foundational code.
Simple and easy. It's this way because we ruthelessly refactor the code base and ensure everything is doing only one thing.

Summary

The Pizza Shop has been a great experience and I feel is a solid example of µObjects.
I hope to have more available in the future; but this will currently serve as my reference example.