Thoughts on Corey Haines talk with JBrains
Tuesday, 4. August 2009, 09:50:31
This post is just to collect my thoughts on Corey Haines' talk with J. B. Rainsberger on moving specificity towards the test.
Rainsberger presents these four elements of simple design:
If we are doing TDD as Uncle Bob prescribes, in very short red/green/refactor cycles, then the "passes test" part becomes a non-issue and goes away. Then, the "is small" goes away because any body of code that has minimized duplication and maximized clarity is unlikely to be unnecessarily large.
This leaves us with these two takeaways from the talk:
Removing duplication is not just code, but also intent. Say and Inventory knows how to format prices, while some controller object knows how to write "No price available" if the Inventory could not find a price for some product. Both of these deal with how to present a price, but they deal with different parts of the presenting. So there is no duplication in the code, but there is duplication in the intent. Both of these pieces of functionality could moved to a view or presentation layer, and then combined into a whole. This removes the duplication of intent.
It sounds like an application of the single responsibility principle, and that's not a bad thing.
As part of the process of removing duplication, one can start by moving the duplicated parts closer to each other. Say we have a Catalog object that knows how to turn barcodes into prices. If I have a test where I pass in a certain barcode and expect to get back the price 12, I could initially just hard-code the number 12 into the Catalog. As I test for more and more barcodes, this turns into a lookup table. Then we can notice the duplication of the hard coded values. If the lookup table is really a map underneath, I can move it to the test and then pass it into the Catalog through the constructor.
This in turn leads the code to naturally evolve toward a model-view-control design. The concerns needs to be separated so they can be passed in and stubbed if need be.
Bad names and clarity is a bit harder to grasp. Frankly, the way he describes things makes it hard to see design effects are caused by removing duplication and which are caused by gaining clarity. So it ends up getting mixed together in his explanation. To me, the structure of the code and the distribution of responsibility are two sides of the same coin. It can be that he meant to say that this is the way it should be. His example of the MVC structured code where the intent and logic of formating prices is duplicated and located in multiple different places, seems to support this conclusion.
Rainsberger presents these four elements of simple design:
- Passes test
- Minimizes duplication
- Maximizes clarity
- Is small
If we are doing TDD as Uncle Bob prescribes, in very short red/green/refactor cycles, then the "passes test" part becomes a non-issue and goes away. Then, the "is small" goes away because any body of code that has minimized duplication and maximized clarity is unlikely to be unnecessarily large.
This leaves us with these two takeaways from the talk:
- Focus on removing duplication leads to well structured code.
- Focus on bad names and clarity leads to a good distribution of responsibility.
Removing duplication is not just code, but also intent. Say and Inventory knows how to format prices, while some controller object knows how to write "No price available" if the Inventory could not find a price for some product. Both of these deal with how to present a price, but they deal with different parts of the presenting. So there is no duplication in the code, but there is duplication in the intent. Both of these pieces of functionality could moved to a view or presentation layer, and then combined into a whole. This removes the duplication of intent.
It sounds like an application of the single responsibility principle, and that's not a bad thing.
As part of the process of removing duplication, one can start by moving the duplicated parts closer to each other. Say we have a Catalog object that knows how to turn barcodes into prices. If I have a test where I pass in a certain barcode and expect to get back the price 12, I could initially just hard-code the number 12 into the Catalog. As I test for more and more barcodes, this turns into a lookup table. Then we can notice the duplication of the hard coded values. If the lookup table is really a map underneath, I can move it to the test and then pass it into the Catalog through the constructor.
This in turn leads the code to naturally evolve toward a model-view-control design. The concerns needs to be separated so they can be passed in and stubbed if need be.
Bad names and clarity is a bit harder to grasp. Frankly, the way he describes things makes it hard to see design effects are caused by removing duplication and which are caused by gaining clarity. So it ends up getting mixed together in his explanation. To me, the structure of the code and the distribution of responsibility are two sides of the same coin. It can be that he meant to say that this is the way it should be. His example of the MVC structured code where the intent and logic of formating prices is duplicated and located in multiple different places, seems to support this conclusion.
WIDGETIZE
How to use Quote function: