오늘날 디자인 패턴이 정말로 필수적인가?

나는 "코더의 직장" 을 읽고 있었고 ,이 책에서 인터뷰 한 일부 전문가들은 디자인 패턴에 대해 열성적이지 않다는 사실에 직면했다.

나는 이것에 대한 두 가지 주요 이유가 있다고 생각합니다.

1. 디자인 패턴은 우리가 그들의 용어로 생각하도록 강요합니다. 다시 말해, 새로운 것을 발명하는 것은 거의 불가능합니다.

2. 디자인 패턴은 영원히 지속되지 않습니다. 언어와 기술은 빠르게 변합니다. 따라서 디자인 패턴은 결국 관련이 없게됩니다.

따라서 특정 패턴없이 올바르게 프로그래밍하는 방법을 배우고 배우지 않는 것이 중요합니다.

요점은 또한 사람들이 문제에 직면 할 때 많은 시간이 없을 때 패턴을 사용하려고한다는 것입니다. 즉, 기존 코드를 복사하여 프로젝트에 붙여 넣으면 약간만 변경되어 작동합니다. 무언가를 변경하거나 추가해야 할 때 개발자는 코드가 아니며 시작에 익숙하지 않기 때문에 어디서부터 시작해야하는지 알 수 없습니다.

돈 때문에 모든 사람이 디자인 패턴의 요점을 놓치고 있다고 생각합니다. 주어진 상황에서 어떤 패턴을 사용해야하는지 궁금합니다. 또한 이름이 있다는 사실을 알기 훨씬 전에 대부분의 패턴을 사용했습니다.

디자인 패턴의 힘은 의사 소통에 있습니다. 내가 제안하는 내용을 자세하게 설명하는 것보다 "전략 사용"이라고 말하는 것이 훨씬 빠릅니다. 이 두 용어의 의미를 모두 알고 있다면 지방 도메인 모델과 트랜잭션 스크립트의 이점을 논의하는 것이 훨씬 쉽습니다. 등등.

그리고 무엇보다도 FooBuilder 클래스의 이름을 지정하면 빌더 패턴을 사용하여 Foo를 생성한다는 것을 알 수 있습니다.

"Observer 패턴이 이상적입니다"라고 말할 때 내가 무슨 말을하는지 모르더라도 쉽게 시작하고 Google을 검색 할 수 있습니다.

그런 의미에서 디자인 패턴의 힘은 결코 사라지지 않을 것입니다.

디자인 패턴은 소프트웨어 사용자로서 우리가 사용하는 공통 언어의 표현력이 향상되었습니다. 이 공통 언어는 필수는 아니지만 문제에 대한 많은 공통 솔루션을 쉽고 빠르게 표현할 수있게합니다. 예를 들어, 싱글턴에 대해서는 "하나의 인스턴스 만 가지고 있지만 정적이고 전역 적으로 만들 수없는 클래스"에 대해 말하는 것보다 훨씬 쉽습니다.

디자인 패턴이 제공하는 솔루션은 유용하지만 해결해야 할 문제에 직면했을 경우 이미 생각한 솔루션입니다. 디자인 패턴을 이해하려면 어느 정도의 성숙도가 필요합니다. 문제를 해결할 필요가 없다면 솔루션에 대한 가치 나 관심을 보지 못할 것입니다.

패턴은 두 가지 주요 목적을 제공합니다.

• 예측 가능한 장력 해결 : 패턴은 작동하는 것으로 알려진 방식으로 특정 장력을 해결하도록 설계되었습니다. 스몰 토크 모범 사례 패턴 (Smalltalk Best Practice Patterns)의 저자 인 켄트 벡 (Kent Beck) 은 유사한 상황에서 전문가가 내리는 결정을 반복하는 방법으로 패턴을 설명합니다. 장력이 동일하게 유지되는 한 (그리고 종종 그렇게하는 경우),이를 해결하는 패턴이 유용하게 유지됩니다.

• 의사 소통 힘 승수 : 패턴을 통해 조금만 말하면됩니다. 이들은 광범위한 문제 공간에 적용 할 수있는 강력하고 이해하기 쉬운 작은 개념을 활용합니다. @pdr의 대답은 패턴의 의사 소통 가치에 관한 것입니다.

디자인 패턴이 혁신을 방해한다는 긍정적 인 생각은 완전히 잘못된 것입니다. 휠이 재발 명될 필요가 없으므로 이미 존재하는 곳을 알아야합니다. 일시적인 패턴은 전체적으로 OOP 시스템에 적용되며 특정 플랫폼이나 언어에 연결되지 않습니다.

사람들이 패턴에 대해 이야기 할 때 제가 싫어하는 것은 어떤 사람들은 패턴에 대해 일종의 집착을한다는 것입니다. 한 번은 클라이언트에게 "두 개 이상의 패턴 (WTF ?!)을 포함하도록 요청"(WTF ?!)하도록 요청했습니다.

아마도 반 패턴 의 개념 은 독일인 일 것이다. 디자인 패턴을 연구하는 것이 소프트웨어 엔지니어가되기위한 중요한 단계라고 생각하지 않습니다. 소프트웨어 설계는 중요하며 종종 프로젝트에서 소프트웨어 설계자의 특권으로 예약되어 있지만 사실적으로 "잘 겔화 된"팀에서 합의에 의해 망치질 수있는 것입니다.

그러나 디자인 패턴과 안티 패턴은 이러한 토론을위한 리소스를 형성합니다. 잘 작동 한 (또는 그렇지 않은) 교훈과 디자인 선택의 결과를 활용 (또는 완화)하는 방법을 이해해야합니다. 좋은 팀 은 그러한 토론을 위해 자신의 어휘를 생각해 낼 수 있지만 실제로 그 일을해온 저자가 실제로 작성한 표준을 참조하는 것은 그리 나쁜 일이 아닙니다.

디자인 패턴에는 두 가지 종류가 있습니다.

1. 복잡한 프로그램을 구성하는 방법에 대한 훨씬 더 많은 범용 패턴- 프로그램을 전혀 이해할 수 없습니다. 더 많은 예제가 발견 될 수 있지만 이것들은 사라지지 않을 것입니다.
2. 상황 패턴 은 구속 조건 (예 : 프로그래밍 언어)에 의해 유도 된 특정 힘에 구속되어있어 힘이 변할 때 관련이 없습니다.

물론 모든 패턴은 상황에 따라 다소 다르지만 일부는 힘이 현실 세계에서, 다른 힘은 도구에서 나옵니다. 도구는 실제보다 훨씬 빠르게 변경됩니다.

디자인 패턴을 읽는 것은 수학을 재창조하는 대신 학습하는 것과 같습니다. 어떤 일이 일어 났는지 제대로 이해 한 후에는 특정 분야에서 큰 진전을 이루지 못합니다. 리먼이 유클리드를 읽지 않았다고 생각하십니까?

동료 나 고객이 "어떻게 작동합니까?"라고 생각하는 시간을 줄이면 디자인 패턴에 이점이 있습니다. 표준화를 위해 표준을 시행하는 것은 의미가 없지만, 어떤 일을하는 일반적이고 잘 이해되는 방법이 있다면, 코더가 그 패턴을 찾아 그것을 기대하는 패턴을 찾을 때마다 당신은 그들과 당신의 직업을 만들었다 쉬워

저는 4 명의 갱이 스스로 디자인 패턴을 다음과 같이 분류한다고 믿습니다.

자주 발생하는 문제에 대한 일반적인 해결책 *

따라서 동일한 유형의 문제가 발생했을 때 패턴이 관련됩니다. 그리고 이것은 "디자인 패턴"이라는 용어에 문제를 일으 킵니다. 패턴은 반복적으로 발생하는 인식 가능한 것입니다. 실제로는 디자인 패턴이없고 문제 패턴이 있습니다.

일부 프로그래밍 언어에는 이러한 문제 중 일부에 대한 고유 한 솔루션이있을 수 있습니다. "디자인 패턴"책은 CLOS를 사용하는 경우 방문자 패턴이 거의 가치가 없다고 언급합니다. 다중 디스패치는 CLOS에 의해 기본적으로 지원되므로 방문자 패턴이 해결하려는 문제입니다.

또한 .NET 프레임 워크에는 이벤트를 여러 리스너에 게시하는 이벤트 메커니즘이 내장되어있어이 컨텍스트에서 관찰자 패턴의 관련성이 떨어집니다.

데스크톱 응용 프로그램에서 웹 응용 프로그램으로 변경 **은 해결해야하는 프로그래밍 문제 유형도 변경합니다. "디자인 패턴"책의 많은 패턴은 데스크탑 응용 프로그램과 관련이 있지만 웹 응용 프로그램과는 관련이 없습니다. 물론 단일 페이지 앱의 경우 이러한 패턴이 클라이언트 측에서 다시 관련 될 수 있습니다.

그러나 디자인 패턴과 "디자인 패턴"또는 "엔터프라이즈 응용 프로그램 아키텍처 패턴"과 같은 책은 초보자 프로그래머가되어 처음으로 새로운 유형의 문제에 직면 할 때 큰 가치가 있습니다. 처음으로 실행 취소 기능을 구현하라는 요청을 받았습니다. "디자인 패턴"책이 아니었다면, 각 구현은 각 상태 변경 작업 후 *** 데이터의 스냅 샷을 저장하는 것과 같았을 것입니다.

예, 패턴의 일부는 시간이 지남에 따라 관련성이 떨어지고 숙련 된 프로그래머가되면 그 패턴에 대해 덜 생각합니다. 그러나 초보자에게는 문제를 해결하는 수단이며 가능한 한 많이 사용하려는 탐구가 아니라는 것을 기억하는 한 초보자에게는 가치가 있습니다.

* 견적은 메모리에서 가져 오기 때문에 100 % 정확하지 않을 수 있습니다

** 내 경험상, 기업이 내부 업무용 응용 프로그램을위한 웹 전달 메커니즘을 선택하는 것이 매우 일반적입니다.

*** 함수형 프로그래밍과 함수형 데이터 구조를 배운 후에는 이것이 오늘날 해결하는 방식 일 수 있습니다.

디자인 패턴에 대한 엄격한 준수는 유해 할 수 있습니다. 패턴은 일반적인 문제에 대한 솔루션으로 문서화되어 있지만 설명서는 아닙니다. 그러나 그것들이 길게 논의되고 어떤 경우에는 효과적인 문제 영역 밖에서 적용되었다고해서 그 가치가 전혀 없다는 것을 의미하지는 않습니다. 그것들은 프로그램 아키텍처를 설계 할 때 활용할 수있는 일련의 원칙들-프레임 워크라고 함-건축가가 솔루션의 작동 방식을보고 싶어하는 인상을 줄 수 있도록합니다. 훌륭한 개발 팀은 그것들을 기능 사양이 아니라 기능의 기초로 간주합니다.