>>106211328
>so in addition to the if and break you had to add another interface, another class, another method and another field
first: not "had to", but chose to
the minimal implementation would be to just add a if and break inside fizzBuzz(), no extra methods (if you were to shoehorn finding a perfect square as inline code into the fizzbuzz loop), no new interfaces or classes. but such an implementation assumes every fizzbuzz instance has to have this break condition
the implementation posted uses composition to add that condition. that way, in one program you can have a standard fizzbuzz from 1 to 100, as well as a fizzbuzz with the extra break condition
also, it actually reuses the Condition interface used in addRule, so you can also use DivisibleBy, IsPrime or any other implementation as a break condition, or use PerfectSquare as another rule condition for building your fizzbuzz variants
creating a new class to implement PerfectSquare isn't some gigantic overhead while adding better code organization (stuff related to calculating a perfect square is just in one class named PerfectSquare) and flexibility (can use it; can ignore it)
>the existing rule abstraction did not anticipate the future correctly
the rule part (condition + output) has remained untouched as the new requirement didn't affect it
also there wasn't even any anticipation of future involved - the refactoring has been done as new requirements arrived
