Timeline for FizzBuzz without hard-coded logic checks
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 7, 2016 at 12:58 | vote | accept | Matt | ||
| Mar 2, 2016 at 21:22 | answer | added | Alexei | timeline score: 4 | |
| Mar 2, 2016 at 20:38 | comment | added | Matt | There should be only 2 factors to the FizzBuzz spec: The counting range and the substitution logic. If they want to change the counting range (count by 2, exponential, random) then refactor the Counter class. If they want to change the substitution logic (include number on all lines, text formatting) then refactor the Catalog class. | |
| Mar 2, 2016 at 20:35 | comment | added | Johan Larsson | Or what happens when the customer wants to change something other than what you planned for? | |
| Mar 2, 2016 at 20:28 | comment | added | Gilles | What happens if you don't change the program? | |
| Mar 2, 2016 at 20:28 | history | edited | 200_success | CC BY-SA 3.0 | edited title |
| Mar 2, 2016 at 20:28 | comment | added | Matt | Maybe, but seeing them code for 3 and 5, and then for 15... What happens when you modify the program for more than 2 numbers? That would get unmanageable quickly. | |
| Mar 2, 2016 at 20:26 | comment | added | Gilles | Personally I think all the FizzBuzz examples with hard-coded logic checks are much more KISS than your example, which is fine as a practice for SOLID but over-engineering otherwise. See : github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition for a truly over-engineered FizzBuzz. | |
| Mar 2, 2016 at 20:17 | history | asked | Matt | CC BY-SA 3.0 |