I find that most of the design patterns are concerned with implementation of a model like mvc, or how to change the implementation with less cost. These are all happened in the implementation phase of a software. So why not call them implementation patterns?
I find that most of the design patterns are concerned with implementation of a model like mvc, or how to change the implementation with less cost.
Design obviously has a big impact on implementation -- every design has to be implemented, after all. But design patterns are fundamentally about design, not implementation. Any given design pattern can be implemented in more than one way, but the concept remains the same. To take that a step further, if you have a project that uses some design pattern, you should be able to replace the implementation of that pattern in the project with a different one, and doing so shouldn't cause any major changes in how the objects relate to each other.
If a pattern such as MVC were an implementation pattern, any projects that use MVC would implement that pattern in substantially the same way. That is, the code would look more or less the same. There are a LOT of MVC frameworks out there, and you can bet that they don't all share the same implementation. Nevertheless, if you've worked with any one of them, you'll find it easy to understand others at a conceptual level because they share the same design.
I'd argue that what is usually known as 'software implementation phase' is a design phase, possibly low level detailed design, but design none the less. The real 'implementation' is in a sense done by compilers and build scripts and therefore automated and out of sight.
Of course why they were originally called design patterns was because they came from architecture (the bricks and mortar type) which is certainly a design phase rather than implementation. Software design patterns were an analogy to Architectural design patterns
A design pattern is a concept that is more of a high level. How you implement those patterns is up to you and it is more at low-level, internal stuff to the design.
They are a general concept that tends to hide the implementation details, thus the name design pattern.
When you say about
change the implementation with less cost, it is a direct side effect of using design pattern. You have all the implementation details encapsulated, so you can change them at will without affecting the clients of your classes.
These are all happened in the implementation phase of a software.
This is not necessarily true, because design patterns might be spotted in the design phase. I agree with you that you should not force design patterns into your design, that they should appear by themselves, but it is a possibility that they appear at the design level, long before you have to worry about the concrete implementation.
Because their design-level aspects matter, not the implementation-level aspects.
Take, for example, the Factory Pattern.
The key concept is that you provide a central entry point to transparently produce various instances of an abstract data type, with the goal of exposing only the factory and the ADT, but not the implementations themselves.
The factory can be a class, a static method, or a free function, and the ADT it instantiates can be returned by interface, by base class, or, dynamic-programming style, as an unspecified type (but documented to contain certain members). Factories can be used to instantiate pure data, classic data-with-code classes, classes that merely wrap a method, or even just functions (lambdas, function pointers, or whatever mechanism the language provides). Those are implementation details though, while the design principle remains the same - make a polymorphic data type abstract by providing only a common interface and a factory mechanism to create instances transparently.