디자인 패턴은 일반적으로 좋은지 나쁜지? [닫은]

얇게 썬 빵 이후 디자인 패턴이 가장 좋다고 주장하는 것을 들었습니다. 또한 디자인 패턴이 "두 번째 시스템 증후군"을 악화시키는 경향이 있고, 지나치게 과도하게 사용되며, 사용자가 실제보다 더 나은 디자이너라고 생각하게 만드는 것으로 들었습니다.

나는 이전 캠프에 가까워지는 경향이 있지만 최근에는 거의 모든 단일 상호 작용이 관찰자 관계로 대체되고 모든 것이 단일 톤인 디자인을보고 있습니다.

장점과 문제점을 고려할 때 디자인 패턴이 일반적으로 좋거나 나쁘고 왜 그런가?

디자인 패턴은 프로그램이나 계약서 작성에 대한 조언이 아닌 언어 입니다. 이들의 주요 용도는 구성 요소 또는 시스템이 어떻게 구현되었는지 (또는 구현 될지) 사후 설명 입니다. 너무 많은 세부 사항으로 들어 가지 않고 청취자가 그것이 어떻게 작동하고 무엇이 중요한지를 이해할 수 있도록 구현을 잘 설명 할 수있는 몇 마디 만 말할 수 있습니다.

Alex : 이봐, 설정 파일은 어떻게 만들어 집니까?

Bob : 공장에 의해 생성되며에 config.h있습니다.

이제 Alex는 구성 파일 작성에 사소한 준비가 필요하다는 것을 알고 있습니다. 그렇지 않으면 작성이 팩토리에 포함되지 않기 때문입니다.

그러나 Bob이 패턴 위조의 가짜이고 여기저기서 패턴을 사용한 경우 Alex는 구성 작성에 대해 아무 것도 말할 수 없었습니다. Bob은 모든 곳에서 팩토리를 사용했기 때문입니다. 이것은 또한 프로그램에서 과도한 복잡성을 초래할 수 있습니다.

따라서 먼저 프로그래밍 한 다음 코드에서 패턴을 발견하십시오. 그것이 그들이 효과적으로 사용되는 방법입니다.

디자인 패턴이 훌륭 합니다. 올바르게 사용하면 코드를 유지 관리하기 쉽고 읽기 쉽고 작업하기 쉽습니다. 좋은 프로그래머가되는 일의 일부는 언제 중지해야하는지 더 알고 있으며, 이후 리팩토링이 더 큰 이점을 가져다 줄 것입니다. 디자인 패턴 만 사용한다고해서 누군가를 훌륭한 프로그래머로 만들지는 않지만 언제 어디서 사용해야하는지 아는 것이 좋습니다. 이 세상의 다른 것들과 마찬가지로 디자인 패턴은 극단으로 남용 될 수 있습니다. 나는 모든 디자인 패턴이 목적을 가지고 직소 퍼즐 조각처럼 완벽하게 제 자리에있는 코드에서 완벽한 균형을 찾고 있다고 오랫동안 알고 있습니다.

올바르게 사용하면 디자인 패턴이 훌륭합니다.

디자인 패턴의 개념은 아키텍처에서 시작되었다는 것을 기억하는 것이 유용합니다. 아키텍처는 크게 다를 수 있습니다. 그러나 모든 건물에는 많은 핵심 아이디어가 있습니다. 이런 식으로 패턴을 디자인의 빌딩 블록으로 생각하십시오. 모든 건물에 모든 가능한 건축 패턴이있는 것은 아닙니다.

집을 디자인한다고 가정 해 봅시다. 정문을 길거리에 두는 대신 집에 들어가기 전에 보호 구역이 필요합니다 (예 : 대기실). 이 영역은 특정 패턴에 맞습니다. 즉, 두 개의 입구, 일부 벽과 아마도 지붕이있을 것입니다. 이 패턴은 문, 창 또는 벽 수를 지정하지 않습니다. 대부분의 구현에서, 2 개의 문, 4 개의 벽 및 아마도 창문이있을 것이다. 그러나이 패턴은 두 개의 입구가있는 닫힌 영역을 나타냅니다. 하나는 집 밖에서 대기실로 연결되고 다른 하나는 집의 나머지 부분으로 연결됩니다. 여기서 중요한 것은 대기실을 원할 경우 지역을 둘러싸고 해당 지역에 두 개의 입구를 제공해야한다는 것입니다.

프로그래밍에서 디자인 패턴의 일반적인 문제는 과도하게 사용되며 문제를 해결하기위한 은총 알이라는 믿음입니다. 그들은 아닙니다. 유용한 프로그래밍 아이디어를 전달하고 생각하는 방법입니다. 특정 언어의 구문 비트가 벽돌과 박격포 인 경우 패턴은 특정 요구를 충족시키기 위해 그것들을 배열하는 유용한 방법을 설명합니다.

디자인 패 터는 반드시 따라야하는 변경 불가능한 계약보다 " 조언 "에 가깝다고 생각합니다. 왜? 당신이 언급 한 이유 때문에 정확하게 말입니다. 모든 것에서 디자인 패턴을 따르는 것은 처음에 패턴을 사용하려는 목적을 무너 뜨리는 코드의 혼란을 초래합니다.

이것이 제가 Java Practices 와 같은 사이트를 싫어하는 이유 입니다. 아이디어 중 일부는 훌륭하지만 저자는 언급 한 모든 단일 디자인 패턴에 따라 전체 프로그램 (및 프레임 워크)을 작성하기로 결정했습니다. 필자는 또한 독자들이 실제 자바 관행이 끔찍하며 전염병처럼 피해야한다고 생각하게하는 큰 따옴표로 모든 기사를 썼습니다.

TL; DR : 디자인 패턴을 사용하십시오. 그들을 남용하지 마십시오

또한 이 스레드를 SO에서 보았습니다. 다른 POV 디자인 패턴에는 사용 된 방법론의 단점을 보완하기위한 상용구 코드가 있습니다. 나는 그 해결 방법을 너무 많이 축하하는 팬이 아닙니다.

나는 중간에 사람들을 선호합니다. 포스터가 올바르게 지적한 것처럼 패턴을 이해한다고해서 훌륭한 개발자가되는 것은 아닙니다. 반면 패턴을 이해하면 훌륭한 개발자가 될 수 있습니다.

개념 단계에서 프로젝트의 패턴 관계를 이해하고 패턴을 보는 것이 좋은 개발자가 될 것입니다.

디자인 패턴은 프로그래밍 문제에 대한 기성품 솔루션을 제공한다고 종종 말합니다. 그들은 어떤 종류의 문제입니까? "객체 동작을 어떻게 변경할 수 있지만 나머지 시스템과 변경 사항을 분리 할 수 ​​있습니까?"

GoF 패턴은 나머지 시스템과의 격리 (캡슐화)를 제공하는 것으로 인식되지만 디자인 패턴을 사용하여 시스템의 어떤 부분에 가변성을 부여하는 것은 어려운 경우가 많습니다. 그들이 제안한 분류 체계 (창조적, 행동 적 및 구조적)를 따르는 대신에, 패턴의 차이점을 도표화하고 패턴을 분류하기위한 두 가지 다른 체계, 즉 라이프 사이클과 컴포넌트 캡슐화 계층을 생각 해냈다.

이 표에서 캡슐화 계층에 대해 알 수 있듯이 디자인 패턴은 구성 요소의 모든 수준에서 적용될 수 있습니다. 그러나 이해가 되겠습니까? 구성 요소가 제안 된 캡슐화 수준에서 동작 변화를 제공해야하며 해당 수준에 적합한 패턴이 사용됩니까? 이러한 질문에 제대로 대답하지 않으면 디자인 패턴이 잘못 적용될 가능성이 높습니다. 자동차 선실에 수직 피벗을 설치할 수 있다고해서 현명한 아이디어는 아닙니다.

돈과 유사하게 디자인 패턴은 자본 비용은 높지만 운영 비용은 낮은 솔루션으로 생각해야합니다. 디자인 패턴은 추가 코딩, 세부 정보 및 디자인이 생성하는 추가 간접비의 개념적 가중치 측면에서 선불입니다. 또한 디자인의 다른 측면을 잠그는 경향이 있습니다. 예를 들어 템플릿 방법을 사용하면 OO 스타일로 프로그래밍해야합니다.

그러나 몇 가지 작은 방식으로 다양하게 밀접하게 관련된 많은 문제를 해결해야하거나 미래에 특정 방식으로 코드를 크게 수정해야하는 경우에는 설계 때문에 선행 비용이 가치가 있습니다. 패턴은 코드에 유연성을 추가합니다. 밀접하게 관련된 두 번째 문제에 대한 수정 또는 솔루션은 패턴이없는 것보다 패턴을 사용하는 것이 훨씬 쉽습니다.

두 캠프는 모두 정확합니다. 올바르게 사용하면 선을위한 힘이되고, 모든 곳에서 산산조각이 나면 나쁜 힘이됩니다.

디자인 패턴은 사용자를 끌어들이는 데 도움이 될 수 있지만 일반적으로 코딩하는 경우에도 마찬가지입니다. 궁극의 도구 상자를 작성하여 유혹을 받기 쉽습니다. YAGNI를 염두에 두어야 응용 프로그램에 필요한 구조의 양을 파악할 수 있습니다. IMO 이것은 개인과 경험 / 판단의 표시입니다.

나는 디자인이 당신의 코드에 끊임없이 적용하려고하는 것이 아니라고 생각합니다. 나에게 그것은 주로 개발자들에게 공통적 인 언어에 관한 것입니다. 모든 것을 반복해서 설명하는 것보다 "빌더 패턴을 따른다"고 말하는 것이 더 쉽습니다.

필자는 현재이 책의 패턴 중 하나를 따르는 많은 코드를 발견하기 때문에 현재 엔터프라이즈 애플리케이션 아키텍처의 패턴을 다시 읽고 있습니다. 의도적으로 패턴 중 하나를 따르도록 선택되지 않았다고 생각하지만 " 트랜잭션 스크립트 " 라고 말할 수 있다면 모든 사람이 그 의미를 명확하게 이해할 수 있습니다.

그러나 새로운 기능이나 새로운 응용 프로그램을 디자인 할 때 준비된 패턴 카탈로그 중에서 선택할 수 있다는 아이디어가 마음에 듭니다. 특정 문제에 대한 검증 된 솔루션이 있다면 왜 모든 것을 다시 발명해야합니까?