What abstractions can we use to reason about any kind of problem we're confronted with?
Design patterns are definitely an abstraction we can use to reason about a problem.
The phrase “mental model” is an overarching term for any sort of concept, framework, or worldview that you carry around in your mind.
That's the definition James Clear gave. It's a term with a very very broad meaning, but that doesn't mean it can't apply to something specific. If you can hold and examine it in your mind, it's a mental model. Design patterns fit into that. Even each specific design pattern (which is what I think you're objecting to) can usefully be seen as a mental model. For example, the Builder pattern can be a mental model of how to create instances of a class with different properties without having constructors for every possible combination of parameters.
Mental models are useful to help you examine and manipulate something in your mind, so when you can use them to better understand the thing they model. All of that definitely applies to individual design patterns. The Builder pattern allows you to better understand how to create instances of a class without an explosion of constructors. You can imagine how adding a method that you optionally call can be better than adding another overloaded constructor.
Functional Programming works as a mental model of how to write software as a collection of functions passing data. It can help you understand computation as isolated operations with specific inputs and outputs, as opposed to mentally modelling computation as encapsulated units of data and behaviour that manipulate each other (which is one way to describe OOP).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Design patterns are definitely an abstraction we can use to reason about a problem.
That's the definition James Clear gave. It's a term with a very very broad meaning, but that doesn't mean it can't apply to something specific. If you can hold and examine it in your mind, it's a mental model. Design patterns fit into that. Even each specific design pattern (which is what I think you're objecting to) can usefully be seen as a mental model. For example, the Builder pattern can be a mental model of how to create instances of a class with different properties without having constructors for every possible combination of parameters.
Mental models are useful to help you examine and manipulate something in your mind, so when you can use them to better understand the thing they model. All of that definitely applies to individual design patterns. The Builder pattern allows you to better understand how to create instances of a class without an explosion of constructors. You can imagine how adding a method that you optionally call can be better than adding another overloaded constructor.
Functional Programming works as a mental model of how to write software as a collection of functions passing data. It can help you understand computation as isolated operations with specific inputs and outputs, as opposed to mentally modelling computation as encapsulated units of data and behaviour that manipulate each other (which is one way to describe OOP).