Hi! Actually inserting the default branch in the factory method (4:06) is not needed. In fact it makes things worse because the compiler will not throw an error during build time if you add another enum value. From the docs: Exhaustiveness Unlike switch statements, the cases of switch expressions must be exhaustive, which means that for all possible values, there must be a matching switch label. Thus, switch expressions normally require a default clause. However, for enum switch expressions that cover all known constants, the compiler inserts an implicit default clause.
I think you're right, the default branch is not needed. I couldn't work out why my compiler was demanding it. I'm sure you'll do better when you do this exercise!
I'm using Arlo's commit notation - an idea by Arlo Belshee that you should include information in your commit about how risky you think the change is. r is less risk than R.
Thanks to do it in java too with intellij, I struggled to find some non equivalency you shown previously with rider. It's weird to see intellij does not automatically update the visibility to protected when pushing down the getSpeed method and force to solve it in this conflict view (not very user friendly imho), then relaunch again the refactoring to make it works :/
In a real system you wouldn't only have the tests to go on - there would be other places constructing these, and then you'd be able to make a more informed decision about that.
@@EmilyBache-tech-coach totally, sometimes, as you put it, the code gets worse before it improves, and I have observed developers stop refactoring at that point.
Great video Emily :)
Thank you!! 😊
Really great demo! You leveraged IntelliJ very nicely.
Thanks!
Thank you for this tutorial, just in 20 minutes I've finally learned how to refactorize!
Happy to hear that!
Hi!
Actually inserting the default branch in the factory method (4:06) is not needed. In fact it makes things worse because the compiler will not throw an error during build time if you add another enum value.
From the docs:
Exhaustiveness
Unlike switch statements, the cases of switch expressions must be exhaustive, which means that for all possible values, there must be a matching switch label. Thus, switch expressions normally require a default clause. However, for enum switch expressions that cover all known constants, the compiler inserts an implicit default clause.
I think you're right, the default branch is not needed. I couldn't work out why my compiler was demanding it. I'm sure you'll do better when you do this exercise!
Great video and channel.
Wonderful, splendid accent 🙂
Nice video! What's the meaning of R or r before the commit message?
I'm using Arlo's commit notation - an idea by Arlo Belshee that you should include information in your commit about how risky you think the change is. r is less risk than R.
Thanks to do it in java too with intellij, I struggled to find some non equivalency you shown previously with rider. It's weird to see intellij does not automatically update the visibility to protected when pushing down the getSpeed method and force to solve it in this conflict view (not very user friendly imho), then relaunch again the refactoring to make it works :/
Yes I'm also surprised that IntelliJ doesn't handle this better.
nice to meet ya
I think that eventually the enum should get removed and the parrot construction be as follows: Parrot parrot = new AfricanParrot(...)
In a real system you wouldn't only have the tests to go on - there would be other places constructing these, and then you'd be able to make a more informed decision about that.
"I think this was a useful first move" - I inferred a sense of uncertainty. How wrong am I?
I'm always open to there being better ways to design code. This demo just shows the best approach I've found so far.
@@EmilyBache-tech-coach totally, sometimes, as you put it, the code gets worse before it improves, and I have observed developers stop refactoring at that point.