올바른 디자인 패턴 선택

저는 항상 디자인 패턴 활용의 중요성을 인식했습니다. 다른 개발자가 가장 적합한 것을 선택하는 방법에 대해 궁금합니다. 순서도와 같은 일련의 특성을 사용하여 결정하는 데 도움이됩니까?

예를 들면 다음과 같습니다.

객체가 관련되어 있지만 구체적 클래스를 지정하지 않으려면 Abstract를 고려하십시오.

인스턴스화가 파생 클래스에 남아있을 때 팩토리를 고려하십시오.

집계 오브젝트의 요소에 순차적으로 액세스해야합니다. 반복자를 시도하십시오.

아니면 비슷한?

c# design-patterns

— 칼 세이건
소스

그 중요성이 무엇이라고 생각하십니까? programmers.stackexchange.com/questions/70877/…

— pdr

다른 개발자들과 궁극적으로 의사 소통 할 수 있도록 가장 적절하고 전체적인 패턴을 인식하는 능력이 중요하다고 생각합니다. 그게 말이 되나요?

— Carl Sagan

@pdr에 동의합니다. 내가해야 할 일에 대해 생각하고 패턴의 이름을 기억하면 다른 사람들도 그 일을 알 수 있도록 클래스 이름을 정하는 데 도움이됩니다.

— Amy Blankenship

과연. 이것은 단순히 "올바른 디자인을 어떻게 선택합니까?"로 요약 될 수 있습니다. 첫째, 올바른 디자인 은 없으며 많은 잘못된 디자인입니다. 그 외에도 더미 경험이 있습니다 (잘못된 것을 골라냅니다).

— Telastyn

답변:

109

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

그들은 아니다.

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

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

그게 낫다.

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

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

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

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

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

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

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

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

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

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

— 로버트 하비
소스

"문제를 찾는 솔루션"에 +1 패턴을 알면 문제를 해결해야 할 때 자연스럽게 발견되는 것을 건너 뛸 수 있습니다. 이것에 대해 배우면 다른 사람들의 코드를 읽거나 다른 프로그래밍 언어를 배우는 것과 같은 방식으로 코딩 및 디자인 기술을 향상시키는 데 도움이 될 것입니다. 그러나 가장 확실하게 코드에 패턴을 맞추기 위해 적극적으로 노력해서는 안됩니다.

— gregmac

저는 항상 디자인 원칙을 익히기 위해 패턴을 살펴보기 시작하는 개발자를 권장합니다. 모든 패턴은 디자인 원칙 중 일부를 나타냅니다 ( 'SOLID'원칙 세트는 하나의 예일뿐입니다).

— ryscl

어쩌면 당신은 응용 프로그램이있는 데코레이터와 외관을 추가 할 수 있습니다. 어려운 원천 개발 지식의 줄임말입니다.

— EBarr

여기에있는 줄을 읽고 디자인 패턴을 선택하는 단계는 다음과 같습니다. 1. 작업중인 코드를 항상 비판적으로 생각합니다. 2. 특정 코드를 기본 문제로 추상화합니다 . 3. 해당 문제에 알려진 해결책이 있습니까 (디자인 패턴) )? 4. 예, 해당 솔루션을 내 세부 사항에 어떻게 적용합니까? 5. 추상 문제에 대한 일반 솔루션을 조정하여 특정 문제에 대한 솔루션을 만듭니다.

— Chris

@Chris는 정말 요약합니다. 패턴 없이 코드를 작성하고 디자인에 필요한 경우 코드를 적절한 패턴으로 리팩토링 하는 것도 아무런 문제가 없습니다 .

나는 나 자신에게 묻습니다.

어떤 문제를 해결하려고합니까?
어떤 소프트웨어 디자인 패턴 (있는 경우)이 동일한 문제를 가장 밀접하게 해결하거나 문제 해결을위한 논리적 경로를 제공합니까?
패턴이 제공하는 추가 추상화 (및 복잡성)가 필요합니까, 아니면 특정 문제에 대해 과도하게 엔지니어링됩니까? 패턴없이 간단하고 효율적으로 문제를 해결할 수 있습니까?

소프트웨어 패턴을 선택하는 프로세스는 데이터 구조를 선택할 때 문제 의 성능 및 메모리 특성 을 평가하고 해당 특성에 가장 잘 맞는 데이터 구조를 선택한다는 점을 제외하고 데이터 구조를 선택하는 프로세스와 다릅니다 .

— 로버트 하비
소스

물론, 그것은 청사진이나 흐름도 대신 경험과 전문가에 관한 것입니다. 나는 당신에게 동의합니다. 그러나 최소한 공장과 같은 가장 중요하고 빈번한 패턴으로 분류 된 고급 치트 시트와 같은 완전한 리소스가 있어야합니다. 패턴을 사용하는 것이 좋습니다. 인터넷에서 그러한 자원을 알고 있습니까?!

— Pmpr

@Trix : sourcemaking.com/design_patterns

— Robert Harvey