디자인 패턴-사용합니까?


44

저는 IT 학생이기 때문에 최근 교사 중 한 명이 디자인 패턴에 대한 개요를 받았습니다. 나는 그들이 무엇인지 이해했지만 일부 측면은 여전히 ​​나를 계속 괴롭 힙니다.

대부분의 프로그래머가 실제로 사용합니까?

경험에 대해 말하면, 프로그래밍하는 동안 문제가 있었고 한동안 해결할 수 없었지만 Google과 몇 시간의 연구로 문제가 해결되었습니다. 웹 어딘가에서 내 문제를 해결할 수있는 방법을 찾으면 이것이 디자인 패턴입니까? 내가 사용하고 있습니까?

또한 개발을 시작할 때 (프로그래머) 자신이 패턴을 찾고 있습니까 (내가 어디에서보아야합니까?)? 그렇다면, 이것은 내가 받아들이 기 시작해야 할 습관입니다.

업데이트 : 프로그래머가 사용하는지 물어볼 때 문제를 해결할 때 "아, 그 패턴을 사용해야한다고 생각합니다."라고 생각합니다.


7
정확한 중복 질문은 아니지만 내 대답은 동일합니다. programmers.stackexchange.com/questions/70877/…
pdr

4
과대 평가되고 과장된 "디자인 패턴"은 대부분 OOP 프로그래밍과 관련이 있습니다. 그리고 OOP에서 가능한 한 멀리 떨어져 있어야하는 많은 이유가 있습니다.
SK-logic

5
Big Ball of Mud를 원하는 것보다 자주 사용하고 있습니다. 농담이야
sashoalm

"적절한 경우"라는 조건문을 가진 유일한 대답은 '그렇다'입니다.
Rig

답변:


114

초보자 프로그래머 였을 때 디자인 패턴이 마음에 들었습니다. 나는 단지 디자인 패턴을 사용하지 않았습니다. 나는 그들을 쳤다. 언제 어디서나 가능합니다. 나는 무자비했다. 아하! 관찰자 패턴! 가져가! 청취자를 사용하십시오! 대리! AbstractFactory! 5 개가 할 때 왜 하나의 추상화 계층을 사용합니까? 많은 숙련 된 프로그래머와 이야기를 나 Go 고 GoF Book 을 읽는 모든 사람 이이 단계를 거칩니다.

초보자 프로그래머는 디자인 패턴을 사용하지 않습니다. 그들은 디자인 패턴을 남용합니다.

최근에는 Single Responsibility Principle과 같은 원칙을 염두에두고 테스트를 먼저 작성하면 패턴 이보다 실용적으로 등장 하는 데 도움 됩니다. 패턴을 인식하면 더 쉽게 진행할 수 있습니다. 나는 그들을 인식하지만 더 이상 코드로 강제로 시도하지 않습니다. 방문자 패턴이 나타나면 아마도 트리를 렌더링하는 것과 트리를 추가하는 것의 유사성에 대해 미리 생각했기 때문이 아니라 복제를 리팩토링했기 때문일 것입니다.

숙련 된 프로그래머는 디자인 패턴을 사용하지 않습니다. 디자인 패턴이 사용합니다.


2
@schlingel-왜 OP Sir에게 전화합니까?
Oded

10
@Oded 나는 이런 상황에서 "Sir"이라고 부를 권리를 갖습니다.
Lunivore

3
네. 알겠습니다. 악의를 의미하지 않습니다!
Oded

1
소비에트 러시아에서 .. :)
Sorantis

5
좋은 대답이지만 마지막 줄에서는 심오 해 지려고했지만 무의미합니다. 어떻습니까? "경험이 풍부한 프로그래머는 디자인 패턴을 선택하지 않고 디자인 패턴을 선택할 수 있습니다."
개럿 홀

43

인식 여부에 관계없이 대부분의 프로그래머 패턴을 사용합니다.

그러나 일상적인 작업에서는 패턴을 염두에두고 프로그래밍을 시작하지 않습니다. 패턴에서 코드가 나타났음을 인식 한 다음 이름을 지정합니다.

공통 패턴 중 일부는 일부 언어에 내장되어 있습니다 (예 : 키워드를 사용하여 C #에 내장 된 반복자 패턴)foreach .

때로는 문제에 대한 일반적인 솔루션으로 사용할 패턴 을 이미 알고 있습니다 (예 : 저장소 패턴 -이미 데이터를 인 메모리 컬렉션으로 표시하려고한다는 것을 알고 있습니다).


13
패턴은 프로그래머가 설계 및 구현 아이디어를 전달하는 데 도움 이되는 언어 이며 시스템을 구현하기 위해 함께 슬롯으로 묶을 수있는 프로그래밍 레고 블록 세트가 아닙니다 .
Mark Booth

27
@DeadMG 왜 그렇습니까?
Kris Harper

11
@DeadMG : 나는 맹목적으로 어리석은 생각에 눈을 멀게했을 것이다-왜 그것이 멍청하다고 생각하는지 알 수 없다 ;-)
Treb

2
@ root45-친구, foreach구조는 프로그래밍을 너무 쉽게 만듭니다. 컬렉션을 반복하는 것과 같은 복잡한 작업이 쉬운 경우 어떻게 다른 사람보다 우월하다고 느낄 수 있습니까? 모든 CRUD 앱에 대해 하나의 어셈블리 코드를 작성합니다. @DeadMG의 정서는 분명한 실용적인 천재 중 하나입니다.
ChaosPandion

8
@DeadMG-.NET 1.0 / 1.1이있을 때 LINQ가 없었습니다. yield그때도 존재하지 않았습니다. 키워드를 제거하여 오래된 코드를 깨는 것이 더 좋은 방법이라고 생각하십니까?
Oded

22

pdr linked 라는 답변에서 알 수 있듯이, 디자인 패턴은 사람들이 어쨌든하고있는 일에 주어진 이름으로 , 사람들이 그 일을 더 쉽게 논의 할 수 있도록 고안되었습니다.

일반적으로 사람들이 작동하는 것으로 밝혀진 솔루션에 대한 통찰력을 제공하므로 수년간의 경험과 시행 착오를 기반으로 할 수 있기 때문에 처음 시작할 때 배우는 것이 좋습니다.

패턴에 포함 된 문제의 동기 부여에 대한 논의는 처음에 문제를 공격하는 좋은 방법에 대한 통찰력을 제공 할 수 있지만, 패턴 지식이 기존의 알려진 솔루션이 있음을 인식하지 못하는 경우 여전히 문제 해결 에 집중해야 합니다. 먼저 문제 .

하나 이상의 기존 패턴을 사용하는 것으로 판명되면 기성품 이름을 사용하여 다른 사람들이 코드를 쉽게 이해할 수 있습니다.


내가 말하고 싶었던 것을 요약하면 +1 : 문제에 집중 한 다음 문제가 패턴이 해결되는 것처럼 보일 경우에만 패턴을 적용합니다.
Joshua Drake

1
디자인 패턴은 사람들이 어쨌든하고있는 일에 주어진 이름 이라는 사실에 대해 +1 합니다 .
miraculixx

12

일반적으로 말해서 코드에서 패턴이 나타나는 경우가 있지만 일반적으로 패턴을 찾지 않고 "아, 브리지 패턴이 내 문제를 해결할 것입니다!"라고 말하지 않습니다.

여기 있습니다. 사람들이 좋은 디자인을 고려하지 않으면 대부분의 패턴이 남용되고 오용됩니다. 패턴은 원자가 아닙니다. 코드는 패턴의 X ​​순열로 구성되지 않습니다. 모든 패턴이 실제로 좋은 아이디어는 아니거나 일부 언어에는 일부 패턴보다 훨씬 우수한 언어 수준의 솔루션이 있다는 것은 말할 것도 없습니다.


+1 : 패턴이 잘못 사용되는 데 동의합니다. 때로는 프로그래머가 패턴을 알고 멋지게 생각했기 때문에 패턴을 사용한 코드를 보았지만 코드가 불필요하게 복잡하고 읽기 어려워졌습니다. 불도저로 너트를 깨는 것처럼. 언어 수준 솔루션과 관련하여 언어 수준 솔루션은 언어에서 직접 지원되는 패턴이 아닙니까? 아니면 차이점은 무엇입니까?
Giorgio

1
@Giorgio : 다른 방식으로 짜여진 일부 패턴은 언어가 특정 것을 깔끔하게 표현할 수있는 방법이 없다는 사실을 해결하는 데 사용됩니다.
데니스

8

예, 내가 본 대부분의 프로그래머는 가장 일반적인 패턴 인 Big Ball of Mud를 사용 합니다. 일반적으로 잘 설계된 아키텍처로 시작하지만 특히 "우리는 디자인 패턴을 사용해야합니다"라고 생각하고 무자비하게 리팩토링하는 경우 특히 여기에서 끝납니다.


2
내 하루를 만들었습니다
dukeofgaming

1
아야. 해당 웹 페이지에는 텍스트 형식이 필요합니다.
Nailer

7

당신은 그들을 사용합니까?

그렇습니다. 숙련 된 프로그래머는 분명히 그렇습니다. 지금은 대부분의 디자인 패턴 (단일 싱글 톤 항목 제외)을 사용하지 않아도됩니다. 그러나 프로그래밍이 많고 시스템이 복잡할수록 디자인 패턴을 사용해야 할 필요성이 커집니다. 그래도이를 피하면 시스템을 확장하고 새로운 요구 사항에 따라 변경해야 할 때 고통을 느끼기 시작합니다.

웹 어딘가에서 내 문제를 해결할 수있는 방법을 찾으면 이것이 디자인 패턴입니까?

반드시 그런 것은 아닙니다. 디자인 패턴은 특정 목표를 달성하기 위해 (또는 특정 문제를 피하기 위해) 클래스, 해당 동작 및 상호 작용을 디자인하는 특정 방법을 나타냅니다. 당신이 겪을 수있는 것은 실제로 디자인 문제가 아니라 특정 API를 프로그래밍하기위한 일련의 특정 단계 일 수 있습니다. 예를 들면 다음과 같습니다. 소켓 연결을 설정하는 특정 순서가 있습니다. 잘못하면 소켓이 통신하지 않습니다. 이러한 일련의 단계는 패턴을 구성하지 않습니다.

당신은 (프로그래머) 패턴을 찾는 자신을 찾으십니까

예. 디자인 패턴은 "예방이 치료보다 낫다"는 원칙을 구현합니다. 예정된 특정 설계 문제를 미리 발견 할 수 있다면 나중에 변경 사항을 수용하도록 대규모 재 설계를 방지 할 수 있습니다. 따라서 디자인 패턴을 미리 알고 응용 프로그램을 빌드 할 때 사용해야하는 위치를 찾아야합니다.

내가 어디에서보아야합니까?

학생이기 때문에 디자인 패턴에 영감을주는 일반적인 문제를 보지 못했을 것입니다. Head First Design Patterns 를 살펴 보는 것이 좋습니다 . 먼저 디자인 문제를 제시 한 다음 특정 패턴이 어떻게 해결 / 피할 수 있는지 보여줍니다.


5

학교에있을 때는 디자인 패턴을 가르쳤습니다. 그리고 대부분의 프로그래밍 경력을 위해 레거시 비 객체 지향 코드로 작업했습니다. 최근 몇 년 동안 나는 그들이 좋은 생각처럼 들리기 때문에 그것들을 배우려고 노력했습니다. 그러나, 나는 책을 집어 들거나 주제에 대한 튜토리얼을 읽으려고 할 때마다 내 눈이 번쩍 들었고 실제로 그들에 대해 실질적인 것을 배우지 않았다고 고백해야합니다.

나는 그것을 공개적으로 인정했다는 것을 믿을 수 없다. 나는 아마 몇 년 동안 내가 설립 한 괴짜 신조를 잃어버린 것 같습니다.


3

유행을 찾지 마십시오

특정 문제에 대한 표준 프로그래밍 솔루션은 디자인 패턴으로 간주 될 수 있으며, 인기도 또는 다른 프로그래머가이를 사용하는지 여부는 중요하지 않습니다.

아직 발명 / 지정되지 않은 디자인 패턴을 사용하고있을 수 있습니다.

그것들을 사용하지 말고 용어로 생각하십시오.

디자인 패턴의 문제점은 프로그래머가 다른 방법으로 문제를 해결하기를 원한다는 것입니다.

디자인 패턴의 디자인 컨벤션에는 해결해야 할 일반적인 문제가 있음을 기억하십시오. 디자인 패턴을 결합하여 더 큰 다른 문제를 해결할 수도 있습니다. 이것은 SOA (Service-Oriented Architectures)에서 일반적으로 나타나는 몇 가지 SOA 패턴을 참조하십시오 .

야생에서 그들을 찾으십시오

적용된 디자인 패턴을 찾을 수있는 많은 오픈 소스 프로젝트가 있습니다. 염두에 두어야 할 한 가지 예는 Joomla입니다. singletons , observers가 있습니다. GUI 라이브러리는 데코레이터 패턴 , 명령 패턴 구현 및 심지어 플라이급 을 가질 것 입니다.

데이터 패턴과 같은 다른 패턴이 있습니다 (예 : Doctrine Project 만 사용), 활성 레코드 패턴 (1.x), 엔티티 관리자 패턴 (2.x), 작업 단위 , 저장소 , 쿼리 오브젝트 , 메타 데이터 맵핑 , 데이터 매핑전략 패턴데코레이터 패턴 과 같은 기타 일반적인 것들 .

선택할 수있는 흥미로운 솔루션이 너무 많습니다. 참조 엔터프라이즈 아키텍처의 마틴 파울러의 패턴은 ,도있다 데이터 모델 패턴 .

때가 오면 그냥 배우세요

그것들을 배우고, 알고, 집착하고, 시간이 다가 오면 프로그래밍 문제 x를 해결하는 방법을 알게 될 것입니다. 그 때까지 이미 더 나은 프로그래머가 될 것입니다.

건축가가 되십시오

문제를 해결하기 위해 패턴 용어로 생각할 수 있으면 효과적으로 소프트웨어 설계자로 변모 할 수 있습니다 . 소프트웨어 아키텍트 자체가되고 싶지 않더라도 솔루션은 기본적으로 더 높은 기술적 품질, 더 깨끗하고 확장 성 (설계 측면에서)을 갖습니다.


1

나는 C ++에서 약 7 년 동안 프로그래밍했으며 약 2 년 전에 패턴을 배웠습니다. 대부분의 패턴에는 아마도 일부 응용 프로그램이 있지만 내 사용법에 따라 다른 패턴보다 낫습니다. 왜 그것들을 사용하는지 생각해야합니다.

반복자 패턴은 실제로 내 코드를 더 혼란스럽게 만들고 불필요한 복잡성을 추가했습니다. STL 벡터 유형에 typedef를 사용하여 동일한 유지 관리 기능을 얻을 수 있습니다. 그리고 반복되는 클래스를 변경하면 반복자 클래스도 변경해야합니다.

그러나 팩토리 방법은 제공하는 다형성에 따라 매우 유용합니다. 나는 누가 그것을 말했는지 잊었지만 "재사용 가능성은 오래된 코드가 새로운 코드를 사용할 수 있다는 것을 의미한다"라는 진술은 팩토리 패턴과 관련이있다.

"디자인 패턴"인지조차 모른 채 몇 년 동안 템플릿 메소드 패턴을 사용해 왔습니다.

경우에 따라 관찰자 패턴이 도움이되었습니다. Observer 패턴의 오버 헤드 복잡성이 가치가 있는지 판단하기 위해 때때로 복잡성을 예측해야합니다. 우리는 약 10 명의 가입자를 사용하는 프로그램을 가지고 있으며 더 많을 수도 있으므로 옵저버 / 가입자 패턴이 도움이되었습니다. 그러나 다른 프로그램에는 두 개의 GUI 디스플레이가 있습니다. 이 프로그램에 대한 관찰자 패턴을 구현했으며, 복잡성을 추가하고 더 많은 디스플레이를 추가 할 것으로 예상하지 않기 때문에 불필요합니다.

항상 패턴을 사용한다고 말하는 사람들은 프로그램이 무한정 복잡하다고 가정하지만 모든 것과 마찬가지로 복잡성 측면에서도 손익 분기점이 있습니다.


1

Lunivore에 추가. 머리 첫 번째 책에서 이것을 인용하고 싶습니다.

        ## **Three steps to great software** ##     
  • 소프트웨어가 고객이 원하는 것을 수행하는지 확인
  • 좋은 객체 지향 원칙을 적용
  • 유지 보수 가능하고 재사용 가능한 설계를 위해 노력하십시오.

시스템이 예상대로 작동하고 나면 세 번째 단계에 있습니다.


0

대부분의 프로그래머가 실제로 사용합니까?

나는 추측 할 것이다. ADO.Net에는 DataAdapter 클래스가있어 패턴을 특수화하려는 영역에 따라 간단한 예를 제공합니다.

경험에 대해 말하면, 프로그래밍하는 동안 문제가 있었고 한동안 해결할 수 없었지만 Google과 몇 시간의 연구로 문제가 해결되었습니다. 웹 어딘가에서 내 문제를 해결할 수있는 방법을 찾으면 이것이 디자인 패턴입니까? 내가 사용하고 있습니까?

아니요, 그건 제 생각에는 디자인 패턴이 아닙니다. 디자인 패턴은 패턴의 레시피를 정의하는 클래스와 메소드의 배열을 갖는 경향이 있습니다.

나는 당신이 한 일을 일반적인 관행으로 생각하고 싶습니다. 복사 및 붙여 넣기 코딩에주의하십시오.

또한 개발을 시작할 때 (프로그래머) 자신이 패턴을 찾고 있습니까 (내가 어디에서보아야합니까?)? 그렇다면, 이것은 내가 받아들이 기 시작해야 할 습관입니다.

때때로 같은 코드가 반복해서 보임에 따라 코드를 패턴으로 리팩토링하는 방법을 찾거나 패턴과 관련된 유사한 문제에 대한 해결책을 기억한다면 그것을 꺼내서 사용할 것입니다. 헤드 퍼스트 디자인 패턴 에는 패턴 이 몇 가지 이상 있지만 리팩토링 은 코딩 패턴을 제안하여 다양한 패턴을 찾게 할 수 있습니다. 다른 가능한 출발점을 원한다면 Microsoft의 패턴 및 실습을보십시오 .


0

학습 패턴은 단지 무언가를 배우는 것이 아닙니다. 프로그래밍 언어로 할 수있는 것을 배웁니다. 나는 패턴이 어떻게 작동하는지 ( 이 경우 복합 패턴) 를 배우는 것만으로 객체 지향 프로그래밍 에 대해 많이 배웠습니다 .

Oded가 언급했듯이 대부분의 프로그래머는 인식조차하지 않고 때때로 사용합니다. 패턴의 장점은 미리 정의 된 패턴으로 특정 문제를 해결할 수 있으므로 건축적인 것에 대해 많이 생각할 필요가 없다는 것입니다.


0

기존 프로젝트 작업을 시작할 때 패턴을 학습합니다. 당신이 배울 수있는 많은 패턴이 있으며, 어떤 프로젝트를 수행하고 있는지에 따라 모든 패턴을 마스터 할 시간이 아닙니다. 하나가 될 때마다 그것이 어떻게 사용되는지 알아보십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.