나는 대학생이고 방금 디자인 패턴에 대해 배우기 시작했고 그 목적을 이해하기 위해 고심하고 있습니다. 나는 그것들을 연구하려고 노력했지만 내가 찾은 모든 자료는 그것들이 전문가가 아닌 학문적 인 방식으로 그들에 대해 이야기하는 것처럼 보인다.
그들의 목적은 무엇이며 배우는 것이 중요합니까?
나는 대학생이고 방금 디자인 패턴에 대해 배우기 시작했고 그 목적을 이해하기 위해 고심하고 있습니다. 나는 그것들을 연구하려고 노력했지만 내가 찾은 모든 자료는 그것들이 전문가가 아닌 학문적 인 방식으로 그들에 대해 이야기하는 것처럼 보인다.
그들의 목적은 무엇이며 배우는 것이 중요합니까?
답변:
디자인 패턴은 의도를 매우 빠르게 전달하는 데 유용합니다. 모든 사람이 팩토리가 무엇인지 알고 있습니다.
정말로, 정말로, 정말로 나쁜 일은 코드를 패턴에 맞추거나 패턴에 따라 책임을 분리하려고 시도하는 것입니다. "이 개체 는 팩토리입니다"라고 말하고 다른 것은 "이 개체는 팩토리이어야합니다"입니다.
디자인 패턴 에 대한 Wikipedia 기사에서 :
패턴 말하기의 유용성은 설계자가 이미 반복해서보고있는 상황을 논의하기위한 공통 용어를 갖는 것입니다.
오랫동안 우리는 소프트웨어 엔지니어링에서 심각한 문제를 겪었습니다. 프로젝트에 새로 온 사람을 고용하고, 프로그래밍 언어를 얼마나 잘 알고 있든 관계없이 귀하의 작업이 어떻게 진행되는지 최신 상태로 유지하는 데 몇 개월이 걸립니다. 그들이 생산적이되기 전에 프로젝트. 하드웨어 엔지니어링에서 그들은 아주 오래 전에이 문제를 해결했습니다. '스키마 다이어그램'이라는 일반적인 용어가 있습니다. 하드웨어 엔지니어를 고용하고, 아침에 하드웨어 프로젝트의 회로도를 제공하고, 연구하고, 저녁이되기 전에 하루가 지나야 납땜 총을 들고 생산성을 높일 수 있습니다. 우리는 더 잘할 수있는 방법을 고안하려고 노력했습니다. 프로그래밍 언어의 표준화는 한 가지 방법이었습니다. 현재 표준 라이브러리 (클래스 라이브러리)는 다른 방법이었습니다. 그러나 가장 중요한 방법 중 하나는 아마도 디자인 패턴 일 것입니다. 그들이 중요합니까? 물론이지!
패턴이 존재하는 두 가지 다른 실질적인 이유가 있습니다.
첫 번째는 이미 잘 설명되어 있습니다. 패턴을 사용하면 개발자 간의 커뮤니케이션에 활력이됩니다. 당신과 나는 둘 다 내가 'Observer'라고 말할 때 매우 구체적인 코드 구조에 대해 이야기하고 있다는 것을 이해한다면, 그 패턴을 사용하는 약간의 코드가 어떻게 작동하는지 매우 빨리 설명 할 수 있습니다. 대안은 시간이 많이 걸리고 오류가 발생하기 쉬운 솔루션을 완전히 설명하는 것입니다. ( "소비자 객체를 설명하고 인터페이스하는이 순수한 가상 클래스를 만든 다음 활성 소비자 목록을 유지하는 클래스를 만들었습니다.")
패턴의 두 번째 이점은 일반적인 문제 형식에 대한 상용 솔루션 형식이라는 것입니다. 패턴을 알고 예를 들어 클래스 사이에 불필요한 연결을 유발하지 않고 생산자 객체에서 여러 소비자 객체로 정보를 얻는 좋은 방법을 찾아야하는 문제가 발생하면 "이것은 "관찰자를위한 직업입니다!" 문제를 해결하는 방법을 즉시 알게됩니다.
이러한 이점은 또한 서로를 강화시킵니다. 이를 통해 특정 공통 클래스 문제를 신속하게 해결할 수 있으며, 완료되면 문제 해결 방법을 매우 신속하게 전달할 수 있습니다.
패턴이 "존재하지 않는"세상과 대조해보십시오. 일반적으로 사소한 디자인 문제가 아닌 이러한 클래스의 문제 중 하나에 부딪 히고 좋은 해결책을 찾는 데 상당한 시간을 소비합니다. 그런 다음 동료가 나타나서 해결 방법을 알고 싶어하며, 방법과 이유에 대해 한 시간을 보냅니다.
이것은 모두 명백한 경고와 관련이 있습니다. 적합하지 않은 패턴으로 문제를 강요하지 마십시오. 패턴이 문제에 맞지 않으면 솔루션이 복잡해지고 패턴의 노력 감소 이점을 잃게됩니다. 또한, 업무가 더 이상 패턴의 의미에 대한 동료의 이해와 맞지 않기 때문에 의사 소통 비용을 잃게됩니다. 실제로 패턴을 잘못 사용하면 동료가 솔루션에 대한 잘못된 이해를하게되므로 전혀 이해하지 못하는 것보다 나 빠지기 때문에 실제로 패턴없는 비용보다 의사 소통 비용을 증가시킬 수 있습니다.
패턴은 아이디어와 개념의 재사용과 그에 대한 의사 소통을위한 공통 / 일관된 플랫폼을 설정하는 것에 관한 것입니다.
우리는 이론적으로 코드 재사용이 좋은 일이라는 데 동의했습니다. 그러나 실제로 그렇게하고 싶은 것보다 어렵다는 것이 밝혀졌습니다 (일부 측면에서 이것이 변화하고 있지만 항상 도전이 될 것입니다) ). 그러나 실제로 우리가 재사용하려는 많은 것은 특정 문제에 대한 솔루션을 구성하기 위해 일종의 템플릿을 사용하는 것입니다. 이것은 패턴입니다. 따라서 문제 X를 해결하기위한 좋은 접근 방식은 패턴 Y를 사용하는 것이며 패턴 Y의 요소는 a, b 및 c이며 벗어납니다. 패턴이 널리 이해되므로 통신 이점을 자세히 설명 할 필요가 없습니다.
패턴에 대한 재미있는 점은 언어와 프레임 워크가 패턴을 구현하여 애플리케이션을 빌드하는 방식 때문에 점점 더 나은 코드 재사용 (더 나은 레고 브릭!)을 얻는 일반적인 효과로 공통 패턴에 대한 더 나은 지원을 제공하기 위해 진화하고 있다는 것입니다. ) 재사용이 용이합니다.
디자인 패턴은 모든 소프트웨어 솔루션을 기반으로하는 알려진 벽돌입니다. 다음과 같은 이유로 중요합니다.
언어에 구애받지 않습니다. 주어진 문제 / 아키텍처 / 태스크에 어떤 디자인 패턴이 적합한 지 알고 나면 모든 패러다임 언어로 구현할 수 있습니다 (C #, Java 또는 Python)-솔루션은 대부분 동일합니다. 구문을 조정합니다. 즉, 동일한 문제 도메인 내에 있거나 도메인 전체에있을 경우 한 언어로 프로그래밍에서 다른 언어로 경험을 이전 할 수 있습니다.
디자인 패턴이 프로그래밍 패러다임에 바인딩되어 있다는 사실에도 불구하고, 객체 지향 프로그래밍을위한 디자인 패턴 (가장 유명한 패턴 , "Gang of Four"패턴 이라고도 함 )을 의미합니다. 패턴을 사용하면 패러다임이 가장 적합한 것을 이해하고 구문을 넘어 설 수 있습니다.예를 들어 사람들이 Basic 또는 Fortran에서 수행 한 방식을 프로그래밍 한 C # 및 Java에서 많은 구현을 보았습니다. 문제를 해결하기위한 완벽한 명령 마음을 가지고 있으며이 솔루션을 렌더링하기 위해 OOP를 사용합니다. , 다형성이없고, 모든 방법은 공용입니다. 디자인 패턴을 사용하면 이러한 개념을 이해하고 실제 개념이 어떻게 작동하는지 확인할 수 있습니다. 함수형 프로그래밍과 같은 다른 패러다임의 디자인 패턴에도 동일하게 적용됩니다.
패턴은 일반적으로 아이디어를 표현할 수있는 편리한 방법 이며 아키텍처에서 컴퓨터 과학으로 왔습니다. 특정 "패턴"의 개념을 이해하면 다른 문제에서이 패턴을 쉽게 인식하고이 패턴을 사용하여 해결할 수 있습니다 (문제를 더 잘 해결하기 위해 약간 수정 된 것 같습니다). Enterprise Software Integration , Source Code Testing 등 수많은 패턴이 있습니다. 컴퓨터 과학 관련 서적에서 패턴을 찾으십시오.
패턴 을 학습하여 모범 사례를 얻는 것 외에도 안티 패턴 을 연구하여 코드에서 바보 같은 실수를 피하는 방법을 쉽게 배울 수 있습니다 . 서로 다른 영역에서 흔히 볼 수있는 실수를 특징으로하는 안티 패턴 형태의 책이 많이 있습니다. 나는 이런 반 패턴의 이름을 좋아한다!
디자인 패턴의 유용성은 선택한 언어에 따라 다릅니다. 더 강력한 언어를 선택할수록 디자인 패턴을 이해하고 구현할 필요가 줄어 듭니다. 디자인 패턴 언어는 신호일 수있다 짜증 내장 기능이 없습니다.
Joe Gregorio는 파이썬에서 디자인 패턴이 부족하다는 것에 대해 크게 이야기 했습니다.