[MattHeard]

I got as far as here:

> If you need to introduce a new pattern, consider refactoring the entire codebase to use this new pattern, rather than creating one-off inconsistencies.

Putting aside the mis-application of "pattern" (which _should_ be used with respect to a specific design problem, per the Gang of Four), this suggestion to "refactor the entire codebase" is impractical and calcifying.

Consistency increases legibility, but only to a certain point. If the problems that your software is trying to solve drift (as they always do with successful software), the solutions that your software employs must also shift accordingly. You can do this gradually, experimenting with possible new solutions and implementations and patterns, as you get a feel for the new problems you are solving, or you can insist on "consistency" and then find yourself having to perform a Big Rewrite under unrealistic pressure.

[Diggsey]

> Putting aside the mis-application of "pattern" (which _should_ be used with respect to a specific design problem, per the Gang of Four)

This is not in any way a mis-application of the word "pattern". There is no exhaustive list of all design patterns. A design pattern is any pattern that is used throughout a codebase in order to leverage an existing concept rather than invent a new one each time. The pattern need not exist outside the codebase.

> Consistency increases legibility, but only to a certain point.

It's the opposite: inconsistency decreases legibility, and there is no limit. More inconsistency is always worse, but it may be traded off in small amounts for other benefits.

Take your example of experimenting with new solutions: in this case you are introducing inconsistency in exchange for learning whether the new solution is an improvement. However, once you have learned that, the inconsistency is simply debt. A decision should be made to either apply the solution everywhere, or roll back to the original solution. This is precisely the point the author is making by saying "consider refactoring the entire codebase to use this new pattern".

This refactoring or removal doesn't need to happen overnight, but it needs to happen before too many more experiments are committed to. Instead what often happens is that this debt is simply never paid, and the codebase fills with a history of failed experiments, and the entire thing becomes an unworkable mess.

[Y_Y]

> "pattern" (which _should_ be used with respect to a specific design problem, per the Gang of Four)

Why is that true? Particularly if you're not an OOP user/believer. It's not like "pattern" is some obscure term of art.

[_a_a_a_]

For consistency, the same design problems should have the same design solutions a.k.a. pattern. If you don't value consistency, feel free to take a different approach every time. That will confuse your users. I used to work with a guy, the simple problem of reading a CSV was done using a library, problem sorted. Out of sheer excitement he then rewrote it was with combinator parsers, then as some astronaut architect functional monstrosity, so complex no one else could comprehend it.

This is how not to do it – for same problem, use same solution. I admit that's an extreme case but it's also a real one and illustrates the issue well.

(also patterns are not specific to OO, nor is OO incompatible with a functional style)

[Y_Y]

Are you replying to the right person? I'm saying that "pattern" need not be restricted to the narrow sense used in the famous "Gang of Four" book[0], not that patterns are inherently bad!

[0] https://www.oreilly.com/library/view/design-patterns-element...

[_a_a_a_]

> I'm saying that "pattern" need not be restricted to the narrow sense used in the famous "Gang of Four" book

I understood that was exactly what you were saying! Sorry, I'd had a drink.

[watwut]

It is not just about legibility. Developers are trying to repeat patterns they see around. If you do not refactor previous places, they will reproduce the outdated pattern. Plus, it makes code reviews frustrating.