최악 또는 가장 좁게 정의 된 디자인 패턴은 무엇입니까? [닫은]

모든 프로그래밍 프로젝트에서 과거 프로그래밍 경험이있는 관리자는 프로젝트의 일부 디자인 패턴을 추천 할 때 빛을 발합니다. 디자인 패턴이 의미가 있거나 확장 가능한 솔루션이 필요한 경우 디자인 패턴이 마음에 듭니다. 예를 들어 프록시, 관찰자 ​​및 명령 패턴을 긍정적 인 방식으로 사용했으며 매일 그렇게합니다. 그러나 팩토리가 나중에 객체를 더 쉽게 만들 수 있지만 코드를 복잡하게 만들고 순수한 오버 헤드이므로 객체를 만드는 한 가지 방법이있는 경우 팩토리 패턴을 사용하는 것이 정말 주저합니다.

그래서 내 질문은 내 미래의 경력과 무작위 패턴 이름을 던지는 관리자 유형에 대한 나의 대답과 관련이 있습니다.

어떤 디자인 패턴을 사용하여 전반적으로 되돌아 갔습니까? 최악의 디자인 패턴은 무엇입니까? 하나의 상황이 이해되는 단일 상황을 제외하고 고려해야 할 패턴은 무엇입니까 (읽기 : 어떤 디자인 패턴이 매우 좁게 정의되어 있습니까)? (아마도 사람들이 디자인 패턴을 사용하는 데있어 가장 큰 버그를 발견하기 위해 아마존의 전반적인 좋은 제품에 대한 부정적인 리뷰를 찾고있는 것과 같습니다.) 그리고 안티 패턴에 대해 이야기하는 것이 아니라 일반적으로 생각되는 패턴에 대해 이야기하고 있습니다. "좋은"패턴.

편집 : 일부 답변으로, 문제는 대부분 패턴이 "나쁜"것이 아니라 "잘못 사용 된"것입니다. 자주 잘못 사용하거나 사용하기 어려운 패턴을 알고 있다면 그 패턴이 해답이 될 수도 있습니다.

나는 나쁜 패턴을 믿지 않으며, 패턴을 잘못 적용 할 수 있다고 생각합니다!

• IMHO 싱글 톤 은 가장 많이 남용되고 잘못 적용되는 패턴입니다. 사람들은 싱글 톤병에 걸리고 대안을 고려하지 않고 어디에서나 싱글 톤의 가능성을보기 시작합니다.
• IMHO 방문자 패턴 은 가장 좁게 사용되며 추가 된 복잡성을 정당화하지는 않습니다. 좋은 pdf는 여기에서 얻을 수 있습니다 . 사전에 모든 방법을 모른 채 데이터 구조에 대해 다른 작업을 수행하면서 트래버스 할 데이터 구조가있는 경우에만 방문자 패턴에 전투 기회를 제공하십시오. 그래도 꽤 :)

이 답변에서는 GOF 패턴 만 고려했습니다. 가능한 모든 패턴을 잘 모를 수도 있습니다.

다른 답변자들이 이미 언급 한 싱글 톤과 방문객을 제외하고는 "악명 높은"디자인 패턴을 모릅니다. IMHO의 가장 큰 문제는 특정 디자인 패턴이 "잘못된"것이 아니라 오히려 패턴을 너무 열심히 적용하는 개발자에서 비롯됩니다.

거의 모든 사람들이 패턴에 익숙해 질 때 "패턴 열병"단계를 겪습니다. 얇게 썬 빵 이후 패턴이 가장 좋다고 생각하면서, 처음에는 가능성이있을 때마다 적용하려고 시도합니다. 결과적으로 패턴 자체가 더 이상 도움이되지 않고 장기적으로 코드를 이해하고 유지하기 어렵게 만드는 패턴 아래에 코드가 묻 힙니다.

결국 우리 대부분은이 단계를 극복하고 자신의 문제가 아닌 실제 문제를 해결하기 위해 패턴을 사용하는 방법을 배우기 시작합니다. 패턴은 가격이 비싸고 복잡성이 증가하며 특정 패턴을 적용하는 것은 시스템의 다른 부분을 단순화하여 코드 / 구성을 전반적으로 이해하고 유지하기 쉽도록하여 복잡성을 추가로 상환 할 때만 정당화됩니다. 그렇지 않은 경우, 가능한 가장 간단한 솔루션을 사용하여 패턴을 피하는 것이 좋습니다.

나는 여기서 사지로 나가서 상속의 과용을 제안 할 것입니다. Java와 같은 견고한 컴파일 타임 다형성 지원이없는 언어에 확실히 가장 적합합니다. 런타임 상속은 하나의 기능에 맞는 도구가 아니라 도구입니다.

다른 사람들은 이미 Singletons에 대한 개인적인 증오와 비슷한 말을 했으므로 여기서는 확장하지 않을 것입니다.

하나씩 일어나는 것. 이제는 안티 ​​패턴 (anti-pattern)이라고하는 GOF 패턴을 사용합니다. 그 이유 중 하나는 Singleton으로 인해 코드를 테스트하기가 더 어렵다는 것입니다.

자주 잘못 사용하거나 사용하기 어려운 패턴을 알고 있다면 그 패턴이 해답이 될 수도 있습니다.

예를 들어이 질문에 표시된 것처럼 WPF 의 MVVM 패턴 을 너무 엄격하게 따릅니다 . 어떤 사람들은 너무 엄격하게 코드 뒤에 코드를 넣지 말고 모든 종류의 이국적인 해킹을 만들어서는 안된다는 지침을 따르려고합니다.

물론 MVVM은 지옥처럼 어려우며 소규모 단기 프로젝트에는 적합하지 않습니다.

WPF 박사는 그의 기사 MV-poo 에서 그것에 대해 아이러니 한 게시물을 작성했습니다 .

GOF 책의 일부 패턴은 C ++에 따라 다릅니다. 즉, 반영 패턴이있는 언어에서는 적용하기가 쉽지 않습니다. 예를 들어, 프로토 타입 패턴은 Java에서 덜 중요합니다.

인터프리터 패턴을 '좁은'패턴으로 간주합니다. 일반적인 문제 해결사를 개발할 가치가있는 일반적인 문제가 있어야합니다. 언어를 발명하고 문법을 정의하며 통역사를 작성할 수있는 특별한 문제에 대해서만 작동합니다. 문제 사례는 문법에서 문장으로 표현할 수 있어야합니다. 나는 당신이 그런 상황을 자주 겪는다고 생각하지 않습니다.

내가 가장 후회하는 것 (가장 열렬하지는 않지만) : 방금 함수를 만들어야했지만 OOP 솔루션을 구현했을 때.

공장. 한 가지 유형 만 만드는 코드를 구현하는 것을 보았습니다. 그것은 완전히 쓸모없는 코드 IMO입니다. 온라인에서 많은 예제가 완전히 고안되었다는 것은 도움이되지 않습니다. 피자 공장?

의존성 주입으로 인해 공장 테스트가 더 쉬울 것입니다. 그러나 필요하지 않을 때 코드를 추가하는 것은 의미가 없으며 JMockit과 같은 모의 프레임 워크를 사용할 수 있으면 테스트 인수가 사라집니다. 프로그램을 간단하게 만들수록 좋습니다. 팩토리는 많은 유형의 유형에서만 실제로 의미가 있습니다 (더 큰 것은 적어도 2 이상을 의미합니다).

하나씩 일어나는 것

나는 싱글 톤에 관해 다른 사람들에게 동의한다. 절대로 사용해서는 안되는 것이 아니라 매우 적은 경우로 제한되어야합니다. 그들은 많은 시간을 게으른 세계로 사용됩니다.

스레드 안전성은 싱글 톤의 한 가지 문제입니다. 싱글 톤이 제대로 생성되지 않는 경우 예외 처리는 또 다른 문제입니다. 특히 "메인 이전"에 생성 된 개체 중 하나 인 경우 오류를 안전하게 잡아낼 수 있는지 항상 알 수는 없습니다. 그리고 나중에 정리하는 문제가 있습니다.

나는 하나의 싱글 톤을 사용하는 것을 선호하고 다른 모든 "wannabe"싱글 톤은 당신의 것을 구독하게한다. 가장 일반적인 싱글 톤 사용은 "음성 이벤트"처리입니다. 이벤트가 발생한 "세계로 브로드 캐스트"하고 이벤트를 처리하는 청취자가 그렇게합니다. 그렇게하면 실제로 듣는 이벤트와 함께 발생하는 이벤트를 분리 할 수 ​​있습니다. (로깅, 신호 등)

방문객

개발자가 의미있는 이름을 생각할 수없고 단지 메소드 visit ()를 호출 할 수 없다는 사실과는 별도로,이 점에 대해 추악한 점은 한 방향으로 확장 성을 추가하는 반면 다른 방향으로 제거하면 확장 성을 추가한다는 것입니다. 방문자가 방문 할 수있는 모든 개체 유형에 대해 방문자가 알아야하는 개체 수

지저분하지만 양방향 확장을 허용하는 것은 가능하지만 이것은 방문자 패턴을 정규 형식으로 완전히 사용하지는 않습니다. 가장 일반적인 응용 프로그램은 개체를 인쇄하는 것입니다. 개체를 인쇄하는 다른 방법과 인쇄해야하는 다른 개체가 있습니다. 이를 양방향으로 확장 할 수 있어야합니다. (인쇄는 모든 종류의 객체를 스트림으로 변환하는 것을 의미합니다 : 파일에 저장 / 콘솔 / GUI에 쓰기 등).

(참고 :이를 약간 다른 패턴 인 문서보기 아키텍처와 혼동해서는 안됩니다).

좀 더 복잡한 패턴의 문제점은 그 변형이 너무 많아서 통신 장치로서의 가치를 크게 상실한다는 것입니다.

내가이 범주에서 생각할 수있는 최악의 범죄자는 MVC 패턴입니다. MVP를 무시하더라도 이러한 각 항목의 역할에는 많은 변형이 있으므로 경계가 어디에 있는지 파악하기 위해 새 프레임 워크에서 한 시간을 소비해야합니다.

나쁜 사람 만 나쁜 패턴이 없습니다.

I 좋겠 분명 무언가를하지만 일부 뒤범벅 매쉬보다 자세한 거의 없습니다 (큐 사악한 악당 음악) 재사용 가능한 (헐떡 거림!) 훨씬 오히려 상속 쉽게 읽을 수있는 코드 InheritAbstractTemplateFaucetSink<Kitchen>.

재사용 가능한 코드가 훌륭합니다! 다른 응용 프로그램에 대해 유사한 논리를 재사용하거나 다시 작성하는 코드를 작성하지 않을 경우 다른 응용 프로그램 코드를 재사용하려는 일부 미친 시도보다 시간이 덜 걸릴 수 있습니다.

더 읽기 위해 posix 헤더 또는 clib의 제정 한 구현에서 일부 C 코드를 열어 패턴을 찾아보십시오. 이 코드는 세계에서 가장 똑똑하고 헌신적 인 프로그래머가 작성했습니다. 얼마나 많은 추상 팩토리 패턴을 볼 수 있는지 알고 있습니까? ... 없음!. 더 좋은 기회는 진행중인 다른 부분을 이해하면 논리를 이해하고 추적하기가 매우 쉽다는 것입니다.

제 요점은 이것이 "패턴"의 대부분이 책과 모델링 소프트웨어를 판매하기 위해 만들어진 코드를 더 잘 만들기 위해 만들어지지 않았다는 것입니다. 프로그래밍에 능숙하다면 아마도 이들 대부분을 피하고 문제를 해결하는 명확하고 간결하며 영리하게 설계된 코드를 작성할 것입니다. 다른 문제가 발생하면 해당 문제를 해결하기 위해 명확하고 간결하며 현명하게 설계된 코드를 작성합니다. 귀하의 목표가 적은 코드를 작성하는 것이라면 프로그래머가 될 수 없다고 생각합니다. 코드 작성을 좋아하고 가능한 많이 작성하고 싶습니다. 내가 이미 쓴 것을 다시 쓸 때 나는 그것을 열 배나 빨리하고 내가 처음했던 것에 만족하지 못한 모든 것을 없애야합니다.

그것으로 나는 당신에게 아마도 컴퓨터 과학에서 가장 좋은 (관련된) 인용문으로 남겨 둘 것입니다.

" 소프트웨어 설계를 구성하는 두 가지 방법이 있습니다. 한 가지 방법은 간단하게 결함을 갖지 않도록하는 것이고 다른 방법은 너무 복잡하여 명백한 결함이 없도록하는 것입니다. 첫 번째 방법은 훨씬 더 어렵습니다 . "

• Tony Hoare (Quicksort 발명자, 현대 OS 디자인의 아버지, Hoare 로직 제작자 및 Turing Award 수상자)

나는 대부분의 패턴에 대한 시간이 있으며, 많은 패턴을 남용 할 수 있음에 동의합니다. 과거에 가장 많이 남용한 것은 추상 템플릿 패턴이라는 것을 알고 있습니다. ASP.NET 웹 양식으로 알려져 있습니다.