refactoring java video series

humble object

The Humble Object Pattern is used to separate code that is hard to test from code that is easy to test. We typically apply this at the boundary where we interact with code we don’t own. For example a framework. We make our own code testable by moving the code that interacts with the third party code to a humble object. It does so little we don’t have to test it.

Only Mock Types You Own

The code on my GitHub

break time dependency

When you need to make changes to legacy code it is often a good idea to start with some refactoring. But to be able to refactor, we first need to put it under test. And this can be quite challenging, especially when the code contains hard dependencies. In this video i am demonstrating a way to break a time dependency and make the code testable again.

The code on my GitHub

replace derived with query (coffee machine part 4)

A derived field is similar to a cache in the sense that you have to actively maintain its state throughout everything that is happening in your domain. So it is similarly complex to cache invalidation. We can replace it with a query method, and get rid of the complication. This doesn’t mean we can’t add caching to the query method later. We can easily add this cross-cutting concern later on using memoization or a decorator pattern if we really need it.

The code on my GitHub

comprehension refactoring (coffee machine part 3)

I am doing a little bit of comprehension refactoring on the model of the coffee machine. When doing comprehension refactoring, we study the code and keep our eyes open for design smells. We start renaming things and move stuff around so the code becomes more reasonable for us.

The code on my GitHub

refactoring to mvc (coffee machine part 2)

I am refactoring the Coffee Machine Cli App that i tested in the last episode towards Model View Controller Pattern.

The code on my GitHub

testing a legacy cli app (coffee machine part 1)

Adding characterization tests to a legacy java code command line application. Running into the legacy code dilemma because of dependencies to the System global.

The code on my GitHub

I found the code thanks to Ted Young, check out his quality coding twitch stream.

Where the code originates from: stackexchange post

Recommended book: Working Effectively With Legacy Code

Recommended talk: Michael Feathers - the deep synergy between testability and good design.

The 3rd party lib i used for Characterization Testing: Seamer.

Post about Preparatory Refactoring.

embellishment to decorator

Moving a cross cutting concern to a decorator can improve flexibility and at the same time reduce complexity of the subject.

the code on my GitHub

lift up conditional

The lift up conditional refactoring is useful for complex and deeply nested conditionals, where related parts are scattered all over the place. I am using the Gilded Rose Kata, which is a perfect example, as it consists of a really complex conditional.

the code on my GitHub

conditional to polymorphism

A conditional, like a switch statement can sometimes be fraudulent. It appears to be a nice and simple solution when it is in fact hiding and provoking duplication. By refactoring to polymorphism we adhere to the ‘Tell Don’t Ask’ principle and get rid of the duplicated parts.

the code on my GitHub

split phase

In a split phase refactoring, we split a tangled piece of code that does more than one thing into distinguished phases that only do a single thing. As a result we can more easily and independently change each of the resulting phases.

the code on my GitHub

extract value object

A value object is a reusable, immutable object that does not only encapsulate a primitive value, but also its behaviour. Identifying and extracting those value objects improve the cohesion in our code, and avoids duplication. Suppose i created a new component that consumed an already existing value object, i would be able to reuse the values methods instead of implementing duplicated code by accident.

the code on my GitHub