프로그래밍에서 디자인 패턴이 얼마나 중요합니까?


19

나는 대학생이고 방금 디자인 패턴에 대해 배우기 시작했고 그 목적을 이해하기 위해 고심하고 있습니다. 나는 그것들을 연구하려고 노력했지만 내가 찾은 모든 자료는 그것들이 전문가가 아닌 학문적 인 방식으로 그들에 대해 이야기하는 것처럼 보인다.

그들의 목적은 무엇이며 배우는 것이 중요합니까?


7
면접에 대해 잘 알고 있습니다!
wim

5
디자인 패턴은 문제를 해결하는 일반적으로 반복되는 명명 된 방법 일뿐입니다. 일반적으로 언어 부족으로 발생합니다.
Jon Purdy

7
디자인 패턴의 목적을 이해하려면 해결해야 할 문제를 이해해야합니다. 이러한 문제를 이해하려면 어려운 일을 한 경험이 필요합니다. :)
MattDavey

답변:


36

디자인 패턴은 의도를 매우 빠르게 전달하는 데 유용합니다. 모든 사람이 팩토리가 무엇인지 알고 있습니다.

정말로, 정말로, 정말로 나쁜 일은 코드를 패턴에 맞추거나 패턴에 따라 책임을 분리하려고 시도하는 것입니다. "이 개체 팩토리입니다"라고 말하고 다른 것은 "이 개체는 팩토리이어야합니다"입니다.


1
따라서 패턴은 모두 있지만 실제로는 코드가 아닙니다. 그렇습니다. 아이디어를 전달하는 것은 좋지만 실제 코드에서 패턴을 볼 수있을 때 더 좋습니다.
Newtopian

3
왜 투표를하지 않습니까? 이것은 실제로 가장 좋은 대답입니다. 코딩은 상식이며 때로는 문제를 해결하기에 적합한 패턴을 빠르게 사용할 수 있습니다. 그러나 일단 사람들이 어디서나 그들을 학대하기 시작하면 그것은 혼란의 한 지옥으로 변합니다.
코더

1
모든 코드에는 모르는 경우에도 일부 패턴이 포함되어 있습니다. 당신이 말하는 디자인 패턴은 재 그룹화되고 널리 사용되고 유용한 패턴의 이름을 지정합니다. 당신이 그들을 알면 더 의식적으로 생각할 수 있습니다. 당신이 당신의 클래스 중 하나를 "ControlDispenser"라고 부르면 아마도 아무도 그것이 무엇을해야할지 알 수 없을 것입니다. 그러나 팩토리 패턴을 알고 있으면 "ControlFactory"라고하며 다른 사람들이 즉시 이해할 수 있습니다.
Olivier Jacot-Descombes

4
그것이 다른 목적에 도움이된다면, 그것은 다른 부류가되어야합니다.
Nate

2
@ 네이트 : 하나의 목적은 여러 패턴 일 수 있습니다. 한 클래스가 하나의 패턴 만 포함해야하는 이유는 없습니다. 패턴은 "원자"책임이 아닙니다. 단일 책임에는 여러 가지 패턴이 필요할 수 있습니다.
DeadMG

26

디자인 패턴 에 대한 Wikipedia 기사에서 :

패턴 말하기의 유용성은 설계자가 이미 반복해서보고있는 상황을 논의하기위한 공통 용어를 갖는 것입니다.

오랫동안 우리는 소프트웨어 엔지니어링에서 심각한 문제를 겪었습니다. 프로젝트에 새로 온 사람을 고용하고, 프로그래밍 언어를 얼마나 잘 알고 있든 관계없이 귀하의 작업이 어떻게 진행되는지 최신 상태로 유지하는 데 몇 개월이 걸립니다. 그들이 생산적이되기 전에 프로젝트. 하드웨어 엔지니어링에서 그들은 아주 오래 전에이 문제를 해결했습니다. '스키마 다이어그램'이라는 일반적인 용어가 있습니다. 하드웨어 엔지니어를 고용하고, 아침에 하드웨어 프로젝트의 회로도를 제공하고, 연구하고, 저녁이되기 전에 하루가 지나야 납땜 총을 들고 생산성을 높일 수 있습니다. 우리는 더 잘할 수있는 방법을 고안하려고 노력했습니다. 프로그래밍 언어의 표준화는 한 가지 방법이었습니다. 현재 표준 라이브러리 (클래스 라이브러리)는 다른 방법이었습니다. 그러나 가장 중요한 방법 중 하나는 아마도 디자인 패턴 일 것입니다. 그들이 중요합니까? 물론이지!


3
토성 로켓을 자전거와 비교하는 것만 큼 소프트웨어 개발과 전기 공학을 비교하는 것이 정확합니다. 두 가지 운송 방법 (A 지점에서 B 지점으로 이동)이지만 완전히 다른 방식과 호환되지 않는 방식으로 진행됩니다.
jer

3
@jer Hmmm, 당신의 비유는 좋지 않습니다. 둘 다 공학 분야입니다. 그들의 유사성이 거기서 끝나더라도, 정의상 여전히 많은 공통점이 있습니다. 우리는 그것들을 동일시하기를 희망하지 않지만, 하나는 다른 것으로부터 배울 것이 많습니다.
Mike Nakis

6
@ 마이크 : 거기 이다 근본적인 차이점은 : 전기 회로 경질 물리적 한계에 의해 제한된다. 소프트웨어 시스템은 인간의 지능의 퍼지 한계에 의해 제약을받습니다.
kevin cline

3
우선, 큰 차이가 없다고 말하지 않았습니다. 둘째, 귀하의 진술도 정확하지 않습니다. 소프트웨어는 언어의 구문에 의해 설정된 엄격한 제약 조건을 준수합니다. 또한 인간의 지능이 전자 부품을 상호 연결할 수있는 순열의 수는 무한합니다. 그러나 다시, 나는 둘을 동일시하거나 심지어 많은 유사성이 있다고 말하려고하지 않습니다. 나는 단지 한 사람이 다른 사람으로부터 배울 것이 많다고 말하고 있습니다.
Mike Nakis

3
소프트웨어는 디자인에 관한 것이기 때문에, 유사한 전기 공학적 비유는 증폭기 회로에서 "전류 미러"와 "네거티브 피드백"에 대한 논의입니다. 이들은 회로도의 개별 구성 요소가 아니라 특정 목적을 달성하는 여러 구성 요소의 배열입니다. 목적을 모른 채 구성 요소를 연결하는 방법을 알면 새로운 사람이 새로운 디자인을 만들 수 없습니다. (즉, 이해의 진보입니다.)
rwong

9

패턴이 존재하는 두 가지 다른 실질적인 이유가 있습니다.

첫 번째는 이미 잘 설명되어 있습니다. 패턴을 사용하면 개발자 간의 커뮤니케이션에 활력이됩니다. 당신과 나는 둘 다 내가 'Observer'라고 말할 때 매우 구체적인 코드 구조에 대해 이야기하고 있다는 것을 이해한다면, 그 패턴을 사용하는 약간의 코드가 어떻게 작동하는지 매우 빨리 설명 할 수 있습니다. 대안은 시간이 많이 걸리고 오류가 발생하기 쉬운 솔루션을 완전히 설명하는 것입니다. ( "소비자 객체를 설명하고 인터페이스하는이 순수한 가상 클래스를 만든 다음 활성 소비자 목록을 유지하는 클래스를 만들었습니다.")

패턴의 두 번째 이점은 일반적인 문제 형식에 대한 상용 솔루션 형식이라는 것입니다. 패턴을 알고 예를 들어 클래스 사이에 불필요한 연결을 유발하지 않고 생산자 객체에서 여러 소비자 객체로 정보를 얻는 좋은 방법을 찾아야하는 문제가 발생하면 "이것은 "관찰자를위한 직업입니다!" 문제를 해결하는 방법을 즉시 알게됩니다.

이러한 이점은 또한 서로를 강화시킵니다. 이를 통해 특정 공통 클래스 문제를 신속하게 해결할 수 있으며, 완료되면 문제 해결 방법을 매우 신속하게 전달할 수 있습니다.

패턴이 "존재하지 않는"세상과 대조해보십시오. 일반적으로 사소한 디자인 문제가 아닌 이러한 클래스의 문제 중 하나에 부딪 히고 좋은 해결책을 찾는 데 상당한 시간을 소비합니다. 그런 다음 동료가 나타나서 해결 방법을 알고 싶어하며, 방법과 이유에 대해 한 시간을 보냅니다.

이것은 모두 명백한 경고와 관련이 있습니다. 적합하지 않은 패턴으로 문제를 강요하지 마십시오. 패턴이 문제에 맞지 않으면 솔루션이 복잡해지고 패턴의 노력 감소 이점을 잃게됩니다. 또한, 업무가 더 이상 패턴의 의미에 대한 동료의 이해와 맞지 않기 때문에 의사 소통 비용을 잃게됩니다. 실제로 패턴을 잘못 사용하면 동료가 솔루션에 대한 잘못된 이해를하게되므로 전혀 이해하지 못하는 것보다 나 빠지기 때문에 실제로 패턴없는 비용보다 의사 소통 비용을 증가시킬 수 있습니다.


2
디자인 패턴이 기성품 솔루션이라는 오해입니다. 그것들은 "패턴"인데 이것이 항상 코드로 번역되는 것은 아닙니다.
Martin York

Erm, 패턴은 항상 코드로 변환됩니다. 거의 문제가됩니다. 문제는 코드가 있거나 코드의 아키텍처 또는 작업중인 제약 조건에 항상 맞지 않을 수 있다는 것입니다. 즉, 패턴이 맞을 수 있다고해서 반드시 사용할 수있는 것은 아닙니다. 그게 당신이 의도 한 것이라고 가정 할 수도 있습니다 (그러나 나는 가정을 좋아하지 않습니다).
Murph

5

패턴은 아이디어와 개념의 재사용과 그에 대한 의사 소통을위한 공통 / 일관된 플랫폼을 설정하는 것에 관한 것입니다.

우리는 이론적으로 코드 재사용이 좋은 일이라는 데 동의했습니다. 그러나 실제로 그렇게하고 싶은 것보다 어렵다는 것이 밝혀졌습니다 (일부 측면에서 이것이 변화하고 있지만 항상 도전이 될 것입니다) ). 그러나 실제로 우리가 재사용하려는 많은 것은 특정 문제에 대한 솔루션을 구성하기 위해 일종의 템플릿을 사용하는 것입니다. 이것은 패턴입니다. 따라서 문제 X를 해결하기위한 좋은 접근 방식은 패턴 Y를 사용하는 것이며 패턴 Y의 요소는 a, b 및 c이며 벗어납니다. 패턴이 널리 이해되므로 통신 이점을 자세히 설명 할 필요가 없습니다.

패턴에 대한 재미있는 점은 언어와 프레임 워크가 패턴을 구현하여 애플리케이션을 빌드하는 방식 때문에 점점 더 나은 코드 재사용 (더 나은 레고 브릭!)을 얻는 일반적인 효과로 공통 패턴에 대한 더 나은 지원을 제공하기 위해 진화하고 있다는 것입니다. ) 재사용이 용이합니다.


4

디자인 패턴은 모든 소프트웨어 솔루션을 기반으로하는 알려진 벽돌입니다. 다음과 같은 이유로 중요합니다.

  1. 언어에 구애받지 않습니다. 주어진 문제 / 아키텍처 / 태스크에 어떤 디자인 패턴이 적합한 지 알고 나면 모든 패러다임 언어로 구현할 수 있습니다 (C #, Java 또는 Python)-솔루션은 대부분 동일합니다. 구문을 조정합니다. 즉, 동일한 문제 도메인 내에 있거나 도메인 전체에있을 경우 한 언어로 프로그래밍에서 다른 언어로 경험을 이전 할 수 있습니다.

  2. 디자인 패턴이 프로그래밍 패러다임에 바인딩되어 있다는 사실에도 불구하고, 객체 지향 프로그래밍을위한 디자인 패턴 (가장 유명한 패턴 , "Gang of Four"패턴 이라고도 함 )을 의미합니다. 패턴을 사용하면 패러다임이 가장 적합한 것을 이해하고 구문을 넘어 설 수 있습니다.예를 들어 사람들이 Basic 또는 Fortran에서 수행 한 방식을 프로그래밍 한 C # 및 Java에서 많은 구현을 보았습니다. 문제를 해결하기위한 완벽한 명령 마음을 가지고 있으며이 솔루션을 렌더링하기 위해 OOP를 사용합니다. , 다형성이없고, 모든 방법은 공용입니다. 디자인 패턴을 사용하면 이러한 개념을 이해하고 실제 개념이 어떻게 작동하는지 확인할 수 있습니다. 함수형 프로그래밍과 같은 다른 패러다임의 디자인 패턴에도 동일하게 적용됩니다.

  3. 패턴은 일반적으로 아이디어를 표현할 수있는 편리한 방법 이며 아키텍처에서 컴퓨터 과학으로 왔습니다. 특정 "패턴"의 개념을 이해하면 다른 문제에서이 패턴을 쉽게 인식하고이 패턴을 사용하여 해결할 수 있습니다 (문제를 더 잘 해결하기 위해 약간 수정 된 것 같습니다). Enterprise Software Integration , Source Code Testing 등 수많은 패턴이 있습니다. 컴퓨터 과학 관련 서적에서 패턴을 찾으십시오.

  4. 패턴 학습하여 모범 사례를 얻는 것 외에도 안티 패턴 을 연구하여 코드에서 바보 같은 실수를 피하는 방법을 쉽게 배울 수 있습니다 . 서로 다른 영역에서 흔히 볼 수있는 실수를 특징으로하는 안티 패턴 형태의 책이 많이 있습니다. 나는 이런 반 패턴의 이름을 좋아한다!


2

패턴은 자신과 다른 개발자가 이해하는 문제를 해결하는 입증 된 방법으로 생각할 수 있습니다. 예를 들어, 문제는 정렬 된 데이터 목록을 만든 다음 연결된 목록을 사용하거나 데이터를 벡터에 넣고 정렬하도록 선택할 수 있습니다. 링크 된 목록 패턴 또는로드 및 정렬 벡터 패턴을 이미 알고있을 수 있으므로이 두 옵션을 모두 알고있을 것입니다. 당신은 각각의 장단점을 알 수 있으며 진행 상황을 이해하기 위해 구현을 볼 필요가 없습니다.


1

나는 당신이 프로그래밍의 시작이라고 생각합니다. 디자인 패턴을 일찍 배우는 것은 아닙니다. 디자인 패턴 학습 및 이해는 소프트웨어 개발 경험을 바탕으로해야합니다. 코딩하는 연습을 더 많이하고 어떤 코드 스타일이 나쁜지를 발견 한 다음 디자인을 개선하기 위해 디자인 패턴을 배우십시오.


1

디자인 패턴의 유용성은 선택한 언어에 따라 다릅니다. 더 강력한 언어를 선택할수록 디자인 패턴을 이해하고 구현할 필요가 줄어 듭니다. 디자인 패턴 언어는 신호일 수있다 짜증 내장 기능이 없습니다.

Joe Gregorio는 파이썬에서 디자인 패턴이 부족하다는 것에 대해 크게 이야기 했습니다.


파이썬에서 디자인 패턴이 부족하다는 링크에 감사드립니다. 편집 : 죄송합니다 !! 그 위치에서 비디오가 제거되었습니다 !! :(
Saurabh Patil

0

디자인 패턴은 소프트웨어 개발에서 흔히 발생하는 문제에 대한 솔루션입니다. 일부 문제에 대한 솔루션은 항상 둘 이상 있으며 디자인 패턴을 통해 이러한 일반적인 문제에 대한 우수한 솔루션 세트를 제공하여 어떤 솔루션이 가장 적합한 지 결정할 수 있습니다.

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