Excellent video, Emily. Note that at 15:08 you push down number_of_coconuts and things blow up. If you look closely at the Push Members Down dialog you have __init__ selected as well as number_of_coconuts. It's nice to see the limitations of automated refactoring in Python, but I see I could learn a few tricks, especially adding and removing parameters from functions and methods.
This is a great example of doing a big "architectural refactoring" while keeping your test suite working, but to be honest I find the original conditional code to be much cleaner than the polymorphism solution- way fewer lines, way fewer characters, way fewer files... why scatter the logic in all these various files when it was so succinctly written initially?
This is an exercise designed for practicing the steps - you're right it's too small to really need this refactoring. Generally you'd want to refactor to subclasses if you had many repeated switches with different behaviour depending on a typecode. It also makes sense to have that design when you need to add a new type - you'll be able to add new code all in one place.
Excellent video, Emily.
Note that at 15:08 you push down number_of_coconuts and things blow up. If you look closely at the Push Members Down dialog you have __init__ selected as well as number_of_coconuts.
It's nice to see the limitations of automated refactoring in Python, but I see I could learn a few tricks, especially adding and removing parameters from functions and methods.
Well spotted! I knew I'd done something wrong. There's always more to learn. Glad I could show you a couple of things too :-)
Please, keep doing Python katas if you can
What is it in particular that you are lacking? Is the code too small to see?
This is a great example of doing a big "architectural refactoring" while keeping your test suite working, but to be honest I find the original conditional code to be much cleaner than the polymorphism solution- way fewer lines, way fewer characters, way fewer files... why scatter the logic in all these various files when it was so succinctly written initially?
This is an exercise designed for practicing the steps - you're right it's too small to really need this refactoring. Generally you'd want to refactor to subclasses if you had many repeated switches with different behaviour depending on a typecode. It also makes sense to have that design when you need to add a new type - you'll be able to add new code all in one place.