> like user input, you just moved your single if statement in the method out to every call site. I guess the author would argue that the boolean should be push

> like user input, you just moved your single if statement in the method out to every call site. I guess the author would argue that the boolean should be pushed up to UI code. Arguably that domain logic belongs in the UI. Possibly a utility method in the UI package. That being said, with all patterns there are exceptions. Following something to absolute purity is going to result in unclear code - polymorphism purity can rapidly cause a spaghetti codebase. Even GoF patterns can easily result in messy code. All patterns are blueprints, not rules. On the topic of boolean values, I'm becoming more and more convinced by the anti-bool pattern. Normally this involves using an enum (usually bit field) when you first declare a parameter. FileOptions options = FileOptions.None; options |= temporary.checked ? FileOptions.Temporary : FileOptions.None; options |= encrypted.checked ? FileOptions.Encrypted : FileOptions.None; FileUtils.createFile("name_temp.txt", "file contents", options); createFile now includes an 'if' and is at odds with anti-if (which is a pattern that I agree with). This is exactly my point, irrespective of whether you use multiple methods (createFile, createTemporaryFile, createEncryptedTemporaryFile, etc.) or polymorphism (File, TemporaryFile, etc.); you're going to end up with unclear code. Increasing clarity is the whole purpose of patterns. Composition (which bitfields are a form of) is the clear winner here and so the anti-if pattern has to be eliminated.