Second-Order Refactoring: Narrow The Question | #47

Another small second-order refactoring for you today. I call it "narrow the question". If you're asking an object for data, ask for exactly what you want to know, instead of what you'd need to compute what you want to know. A very simple example: the PlayerView wants to disable/enable some of its controls when the Player is actively playing. In the "before" code, PlayerView asks the Player for its PlayerState and decides, based on its value, whether that means the Player is playing or not.In the "after" code, PlayerView just directly asks the Player if it is playing. This is such a tiny change: literally cut/paste the condition out of PlayerView and wrap it in a new function in Player. Multi-class refactoring doesn't get much simpler than this. But the impact is real. In the Before, PlayerView has to know about PlayerState, and it has to know the meaning of Player having certain PlayerState values. In the after, PlayerView just has to know that a Player knows whether or not it's playing.  Episode 47 is live! If you are interested in becoming a part of the conversation, Click here to join the Change-Harvesting Camerata Today! --- If you have any feedback you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. You can also read the full transcription of this podcast over on GeePawHill.org.