디자인 패턴을 언제 사용할지 어떻게 알 수 있습니까?

디자인 패턴을 언제 사용할지 어떻게 알 수 있습니까?

---

누구나 GoF 책을 읽고 디자인 패턴이 무엇이며 어떻게 사용하는지 배울 수 있지만, 디자인 패턴이 문제를 언제 해결하는지 알아내는 과정은 무엇입니까? 패턴에 대한 지식이 디자인을 주도합니까, 아니면 패턴을 사용하여 디자인을 변경하는 방법을 알아낼 수있는 방법이 있습니까?

즉, 패턴에 대한 패턴이 있습니까?

---

디자인 패턴은 문제 를 해결할 수 있는 구조를 제공해야합니다 . 실제 문제를 해결할 때 디자인 패턴에 맞는지 확인하기 위해 해당 문제에 대한 솔루션의 여러 가지 작은 변형 을 고려해야 합니다. 특히 디자인 패턴을 맞추기 위해 문제 또는 솔루션을 일반화해야 할 것입니다.

대답은 예술입니다. 디자인 패턴을 아는 것은 확실히 중요한 단계입니다. 이런 종류의 것에 익숙해지는 한 가지 방법은 패턴뿐만 아니라 디자인 패턴의 응용 을 연구하는 것입니다 . 한 패턴의 다양한 응용 프로그램을 보면 시간이 지남에 따라 작업을 패턴에 매핑하는 데 도움이 될 수 있습니다.

---

O'Reilly의 Head First Design Patterns 를 읽는 것이 좋습니다 . 이것은 이러한 패턴이 실제 세계에서 어떻게 사용될 수 있는지 설명합니다.

나는 또한 패턴을 염두에두고 디자인을 너무 많이 시도하지 않는 것을 덧붙일 것입니다. 또한 패턴이 해결하는 데 도움이 될 수있는 "코드 냄새"를 찾으십시오.

---

대부분의 사람들이 괴롭히지 않는 패턴의 기본 개념이 있습니다. 그것들을 데이터 구조 나 알고리즘으로 생각하지 마십시오.

대신 메모를 전달하거나 편지를 보내는 것과 같은 메시지를 서로에게 보내는 사람들로 코드를 생각하십시오. 각 개체는 '사람'입니다.

'사람'을 구성하는 방식과 그들이 서로에게 메시지를 보내는 데 사용하는 패턴이 패턴입니다.

---

질문을 뒤집으십시오. 패턴 mtch는 "내 문제에 맞는 패턴"입니다. 배열에서 요소를 찾는 매우 간단한 패턴을 고려하십시오. C에서는 다음과 같습니다.

TYPE_t ary[SIZE] = // ... gets initialized somehow
size_t ix ;        // Your index variable

for(ix=0; ix < SIZE; ix++){
    if (ary[ix] == item) {
       return ix ;
    }
}

코드를 보지 않고 "어디에서 사용할 수 있습니까?"라고 생각하고 문제를보고 "배열에서 요소를 찾는 방법을 알고 있습니까?"라고 말합니다.

더 광범위한 패턴은 실제로 동일한 방식으로 작동합니다. 자주 변경되지 않는 데이터 구조의 복사본이 많이 있어야합니다. 따라서 "Flyweight"라고 생각하게됩니다. 네트워크 경계의 양쪽에 존재하는 무언가를 원합니다. 프록시라고 생각합니다.

패턴, 특히 GoF를 공부할 때 "이 패턴이 필요한 상황은 무엇입니까? 이전에이 패턴을 본 적이 있습니까? 이전 작업에서 이것을 무엇에 사용할 수 있었습니까? 내 삶에서이 예제를 어디에서 찾을 수 있습니까? "

---

디자인 패턴? 당신은 그들에 몸을 담그고 있습니다!

디자인 패턴에 특별한 것은 없으며 단지 디자인 패턴 일뿐입니다. 모든 개발은 디자인 패턴을 사용합니다. 객체 지향 프로그래밍에는 일반적으로 바람직한 것으로 간주되고 표준 디자인 패턴이 된 특정 디자인 패턴 세트가 있습니다. 그러나 바람직하지 않거나 다른 방식으로 무관심한 디자인 패턴 (예 : 디자인 안티 패턴 )과 발견되지 않거나 문서화되지 않은 패턴도 있습니다.

프로그래밍 할 때 패턴 사용을 피할 수 없습니다. 그러나 사용중인 패턴과 특정 패턴이 유용하고 유용하지 않은 경우에 대해 더 잘 알 수 있습니다. GoF 책 에서 표준 디자인 패턴을 연구하면 코드 냄새 및 리팩토링에 대해 배우는 것과 마찬가지로 도움이 될 것 입니다. 특정 디자인이나 디자인 패턴을 사용해야하는시기에 대한 정답은 없습니다. 어떤 패턴을 언제 어디서 사용해야하는지 알기 위해서는이를 사용하고 구현하는 경험을 쌓아야합니다.

---

경험. 패턴과 실제 사용 사례를 알아보십시오. 디자인 결정을 내릴 때마다 알고있는 패턴이 적용되는지 생각해보십시오. 시간이 지남에 따라 더 나아지고 더 넓은 범위의 문제에 패턴을 적용하는 새로운 방법을 발견하게됩니다.

---

내가 찾은 또 다른 훌륭한 책은 다음과 같습니다.

패턴으로 리팩토링

언제, 어디서, 어떻게 기존 코드를 패턴으로 변경할 수 있는지 보여줌으로써 개념을 훨씬 더 잘 이해하고 사용할 수있는 위치를 식별 할 수있게되었습니다.

---

Rian van der Merwe는 2012 년 6 월 Smashing Magazine에 이에 대한 훌륭한 기사 를 썼습니다 . 여기에 몇 가지 중요한 글 머리 기호가 있습니다.

디자인 패턴은 다음 두 가지 이유로 유용합니다.

1. 패턴은 이미 해결 된 문제를 해결할 필요가 없기 때문에 시간을 절약합니다.
2. 패턴은 디자이너들 사이에서 채택이 증가함에 따라 사용자가 작업 방식에 익숙해 지므로 공통 디자인 요소를 접할 때인지 부하가 ​​줄어들 기 때문에 웹을 더 쉽게 사용할 수 있습니다.

van der Merwe는 다음과 같은 경우 패턴 분리를 고려할 것을 권장합니다.

1. 새로운 방식은 사용성을 경험적으로 개선합니다.
2. 확립 된 방식은 구식이됩니다.

---

How did you learn when to use an if statement?

I liken it to that because its a larger construct that you need to know the ins and outs of before you can use it effectively. An if statement solves a class of problems needing branching. A bridge pattern solves a class of problems. I really don't view them any differently.

---

If you know the patterns, then they become tools in your toolbox. When you look at a task, you select from your tools. At that point you should have a pretty good idea which tool is the best fit for a given problem. This is where formulas stop working and you actually do engineering work.

---

I agree that just learning the patterns is not enough. The problem with most books is that they do not provide real-world examples. I've heard that Head First Design Patterns, as some suggested earlier, is a good one.

Another thing is that most books are intentionally not language-specific, which may be both a good or a bad thing for you. However important is to understand a pattern in general, it is equally important to know how to implement it well. I've come across a book called C# 3.0 Design Patterns which devotes just about equal ink to both of these unseparable aspects.

---

I had this same question when I first encountered design patterns. I appreciated the concepts, but didn't know when or how to apply them. My initial approach was to look for applicability during the design phase. Once you have a block diagram and semi-clear responsibilities for each block, its not too hard to take the responsibilities and cross reference them with a decent reference book. Several good ones have been mentioned here, but the GoF one should be on your list. The next step is to look for improvements in the design based on what you see in the patterns.

---

The concept of a design pattern has been taken from structural engineering, as with many practices in software engineering. If you consider building a structure, there are decisions that need to be made on how to build that structure to achieve the goals set out. When making those decisions, you will have a set of requirements to work from. It may be something as simple as Bridge must be able to support X tons at one time, or have a particular tensile strength to allow enough movement in wind etc. An architect would use prior knowledge of other builds to make those design choices. He/She would be very unlikely to try to solve the problem from scratch.

Software Engineering and Design Patterns are exactly the same. They are simply common solutions to common problems. If you know the design patterns, then when you are working through a design, and particular part of a system requires something that fits a design pattern you have, then use it. Don't try to fit a system round a design pattern, fit design patterns in to your system (where they fit). Just try to think of them as a set of solutions to reduce the amount of design work you need to do, and be cautious of over-engineering your solutions to cram in as many design patterns as you can. This will just serve to make your solution unmaintainable and probably quite buggy.

---

A design pattern is a generic description on how to solve a common problem. There're 2 things we should pay attention to:

First, it is a Generic description; it's not the concrete solution, and it's not a complete recipe either, it's just a description on how the solution would look like in order to approach a common problem.

Second, the problem is question is a common problem:, that means this problem has been encountered many times before, and over time people developed a description for how an ideal solution can be applied to this commonly repeated problem.

따라서 일반적이지 않은 새로운 문제가 발생하는 경우이를 해결하기 위해 디자인 패턴을 사용하지 않거나 최소한 직면 한 모든 종류의 문제를 해결하기 위해 디자인 패턴을 도구로 만들지 마십시오.

참고 URL : https://stackoverflow.com/questions/85272/how-do-you-know-when-to-use-design-patterns