Cost of Change during evolution<\/strong><\/p>\n There are some language structures that make Evolutionary Design<\/a> difficult. One of them is the constructor. When I evolve the code, I often understand that one more parameter is needed for the constructor. Because of this I need to minimize the cost of change of the constructor. The best way I know to do that is by creating a builder. In this way I will call the constructor only once, in the builder. So my cost of change is really small.<\/p>\n Duplication<\/strong><\/p>\n If I need to introduce a new design concept, I make sure before that I minimized the duplication connected to that new design concept. Calling new Board(…) many times is a clear sign of duplication. This duplication would make the code evolution considerably slower.<\/p>\n State Immutability<\/strong><\/p>\n Testing becomes easier when state does not change during the life cycle of the object<\/a>. Or, there are no setters on any object. That is why I use constructors and private fields.<\/p>\n Fluent Builder A builder is called fluent<\/a> when it looks like playerBuilder.withName(“Adi”).withAge(7).withColor(“Red”).build(). If let’s say I need to introduce a new characteristic to my player, I can always add a new method to the PlayerBuilder. And I would have something like playerBuilder.withName(“Adi”).withAge(7).withColor(“Red”).withExperienceLevel(“Beginner”).build().<\/p>\n Focused Tests with Idempotence Having this type of builder also lets me have focused tests. I don’t want my test that needs only Age to contain Name. So I want to be able to have playerBuilder.withAge(34).build(). In this case all the values for all the other fields of Player will have a default value that is not generating any side-effects in the system. We could call this characteristic an idempotence<\/a> of the builder.<\/p>\n <\/p>\n Check the video below with the codecast:<\/p>\n
\n<\/strong><\/p>\n
\n<\/strong><\/p>\nVideo<\/h2>\n