오늘날의 코딩 세계에서 중요한 오해는 패턴이 빌딩 블록이라는 것입니다. 당신이 가지고 AbstractFactory여기와 Flyweight어쩌면 거기 Singleton거기 및 XML과 프레스토와 함께 연결하면 작동하는 응용 프로그램을 가지고있다.

그들은 아니다.

흠, 그것은 충분히 크지 않았다.

패턴은 빌딩 블록이 아닙니다

그게 낫다.

패턴은 문제가있는 것을 발견 할 때 사용하는 것입니다. 패턴이 제공하는 유연성이 필요하거나 구성 파일에서 약간의 언어를 만들 때 우연히 발견되어 “대기” 잠깐만, 이것이 내가 작성하고있는 독자적인 통역사입니다. 이것은 알려진 문제이며 통역사 패턴을 사용합니다 . “

그러나 코드에서 발견 하는 것이 아니라 시작하는 것이 아니라는 점에 유의하십시오 . 자바의 제작자는 시작에 “오, 우리는 정수에서 플라이급을 놓을 게요”, 오히려 할 수있는 성능 문제 실현 말하지 않았다 해결 a로 플라이급를 .

따라서 올바른 패턴을 찾는 데 사용하는 “흐름도”가 없습니다. 패턴은 반복해서 발생하는 특정 유형의 문제에 대한 해결책 이며 그 주요 부분은 패턴으로 증류됩니다.

패턴으로 시작하는 것은 해결책이 있고 문제를 찾는 것과 같습니다. 이것은 나쁜 것입니다. 그것은 과도한 엔지니어링과 궁극적으로 디자인의 융통성이 없습니다.

코드를 작성할 때 팩토리를 작성하고 있음을 알게되면 “아하! 그 공장을 쓰려고합니다.”라고 말하고 팩토리 패턴을 아는 지식을 사용하여 다음 비트를 빠르게 작성하십시오. 팩토리 패턴을 재발견하지 않고 코드. 그러나 “여기에는 수업이 있습니다. 융통성있게 수업을 드리겠습니다.”

다음은 Erich Gamma ( Gamma, Helm, Johnson 및 Vissides ) 와의 인터뷰에서 발췌 한 것입니다. 디자인 패턴 사용 방법 :

모든 패턴을 사용하는 것은 나쁜 일입니다. 왜냐하면 합성 설계, 즉 아무도 필요로하지 않는 유연성을 가진 추론 적 설계로 끝날 것이기 때문입니다. 요즘 소프트웨어는 너무 복잡합니다. 우리가해야 할 일을 추측 할 여유가 없습니다. 우리는 실제로 필요한 것에 집중해야합니다. 이것이 패턴 리팩토링을 좋아하는 이유입니다. 사람들은 특정 종류의 문제 나 코드 냄새가 날 때 요즘 사람들이 패턴 도구 상자로 가서 해결책을 찾을 수 있다는 것을 배워야합니다.

“사용시기,시기”에 대한 최상의 도움말은 소프트웨어 디자인 패턴 의 Wikipedia 페이지 일 가능성이 높습니다 . “분류 및 목록”섹션에는 각 패턴의 범주와 작동 방식이 설명되어 있습니다. 플로우 차트가 없습니다. 설명은 “사용시기,시기”에 대한 짧은 스 니펫으로 가장 적합 할 것입니다.

프로그래밍 영역마다 다른 패턴이 있습니다. 웹 디자인에는 고유 한 패턴 세트가 있고 JEE (웹 디자인 아님)에는 다른 패턴 세트가 있습니다. 재무 프로그래밍의 패턴은 독립형 응용 프로그램 UI 디자인의 패턴과 완전히 다릅니다.

어떤 시도를 나열하는 그래서 모두는 본질적으로 불완전하다. 하나를 찾아서 어떻게 사용하는지 알아 내면 결국 제 2의 성격이되므로 다시 언제 어떻게 사용해야하는지에 대해 생각할 필요가 없습니다 (누군가가 그것을 설명 할 때까지).

답변