저는 IT 학생이기 때문에 최근 교사 중 한 명이 디자인 패턴에 대한 개요를 받았습니다. 나는 그들이 무엇인지 이해했지만 일부 측면은 여전히 나를 계속 괴롭 힙니다.
대부분의 프로그래머가 실제로 사용합니까?
경험에 대해 말하면, 프로그래밍하는 동안 문제가 있었고 한동안 해결할 수 없었지만 Google과 몇 시간의 연구로 문제가 해결되었습니다. 웹 어딘가에서 내 문제를 해결할 수있는 방법을 찾으면 이것이 디자인 패턴입니까? 내가 사용하고 있습니까?
또한 개발을 시작할 때 (프로그래머) 자신이 패턴을 찾고 있습니까 (내가 어디에서보아야합니까?)? 그렇다면, 이것은 내가 받아들이 기 시작해야 할 습관입니다.
업데이트 : 프로그래머가 사용하는지 물어볼 때 문제를 해결할 때 “아, 그 패턴을 사용해야한다고 생각합니다.”라고 생각합니다.
답변
초보자 프로그래머 였을 때 디자인 패턴이 마음에 들었습니다. 나는 단지 디자인 패턴을 사용하지 않았습니다. 나는 그들을 쳤다. 언제 어디서나 가능합니다. 나는 무자비했다. 아하! 관찰자 패턴! 가져가! 청취자를 사용하십시오! 대리! AbstractFactory! 5 개가 할 때 왜 하나의 추상화 계층을 사용합니까? 많은 숙련 된 프로그래머와 이야기를 나 Go 고 GoF Book 을 읽는 모든 사람 이이 단계를 거칩니다.
초보자 프로그래머는 디자인 패턴을 사용하지 않습니다. 그들은 디자인 패턴을 남용합니다.
최근에는 Single Responsibility Principle과 같은 원칙을 염두에두고 테스트를 먼저 작성하면 패턴 이보다 실용적으로 등장 하는 데 도움 이 됩니다. 패턴을 인식하면 더 쉽게 진행할 수 있습니다. 나는 그들을 인식하지만 더 이상 코드로 강제로 시도하지 않습니다. 방문자 패턴이 나타나면 아마도 트리를 렌더링하는 것과 트리를 추가하는 것의 유사성에 대해 미리 생각했기 때문이 아니라 복제를 리팩토링했기 때문일 것입니다.
숙련 된 프로그래머는 디자인 패턴을 사용하지 않습니다. 디자인 패턴이 사용합니다.
답변
인식 여부에 관계없이 대부분의 프로그래머 는 패턴을 사용합니다.
그러나 일상적인 작업에서는 패턴을 염두에두고 프로그래밍을 시작하지 않습니다. 패턴에서 코드가 나타났음을 인식 한 다음 이름을 지정합니다.
공통 패턴 중 일부는 일부 언어에 내장되어 있습니다 (예 : 키워드를 사용하여 C #에 내장 된 반복자 패턴)foreach .
때로는 문제에 대한 일반적인 솔루션으로 사용할 패턴 을 이미 알고 있습니다 (예 : 저장소 패턴 -이미 데이터를 인 메모리 컬렉션으로 표시하려고한다는 것을 알고 있습니다).
답변
pdr linked 라는 답변에서 알 수 있듯이, 디자인 패턴은 사람들이 어쨌든하고있는 일에 주어진 이름으로 , 사람들이 그 일을 더 쉽게 논의 할 수 있도록 고안되었습니다.
일반적으로 사람들이 작동하는 것으로 밝혀진 솔루션에 대한 통찰력을 제공하므로 수년간의 경험과 시행 착오를 기반으로 할 수 있기 때문에 처음 시작할 때 배우는 것이 좋습니다.
패턴에 포함 된 문제의 동기 부여에 대한 논의는 처음에 문제를 공격하는 좋은 방법에 대한 통찰력을 제공 할 수 있지만, 패턴 지식이 기존의 알려진 솔루션이 있음을 인식하지 못하는 경우 여전히 문제 해결 에 집중해야 합니다. 먼저 문제 .
하나 이상의 기존 패턴을 사용하는 것으로 판명되면 기성품 이름을 사용하여 다른 사람들이 코드를 쉽게 이해할 수 있습니다.
답변
일반적으로 말해서 코드에서 패턴이 나타나는 경우가 있지만 일반적으로 패턴을 찾지 않고 “아, 브리지 패턴이 내 문제를 해결할 것입니다!”라고 말하지 않습니다.
여기 있습니다. 사람들이 좋은 디자인을 고려하지 않으면 대부분의 패턴이 남용되고 오용됩니다. 패턴은 원자가 아닙니다. 코드는 패턴의 X 순열로 구성되지 않습니다. 모든 패턴이 실제로 좋은 아이디어는 아니거나 일부 언어에는 일부 패턴보다 훨씬 우수한 언어 수준의 솔루션이 있다는 것은 말할 것도 없습니다.
답변
예, 내가 본 대부분의 프로그래머는 가장 일반적인 패턴 인 Big Ball of Mud를 사용 합니다. 일반적으로 잘 설계된 아키텍처로 시작하지만 특히 “우리는 디자인 패턴을 사용해야합니다”라고 생각하고 무자비하게 리팩토링하는 경우 특히 여기에서 끝납니다.
답변
당신은 그들을 사용합니까?
그렇습니다. 숙련 된 프로그래머는 분명히 그렇습니다. 지금은 대부분의 디자인 패턴 (단일 싱글 톤 항목 제외)을 사용하지 않아도됩니다. 그러나 프로그래밍이 많고 시스템이 복잡할수록 디자인 패턴을 사용해야 할 필요성이 커집니다. 그래도이를 피하면 시스템을 확장하고 새로운 요구 사항에 따라 변경해야 할 때 고통을 느끼기 시작합니다.
웹 어딘가에서 내 문제를 해결할 수있는 방법을 찾으면 이것이 디자인 패턴입니까?
반드시 그런 것은 아닙니다. 디자인 패턴은 특정 목표를 달성하기 위해 (또는 특정 문제를 피하기 위해) 클래스, 해당 동작 및 상호 작용을 디자인하는 특정 방법을 나타냅니다. 당신이 겪을 수있는 것은 실제로 디자인 문제가 아니라 특정 API를 프로그래밍하기위한 일련의 특정 단계 일 수 있습니다. 예를 들면 다음과 같습니다. 소켓 연결을 설정하는 특정 순서가 있습니다. 잘못하면 소켓이 통신하지 않습니다. 이러한 일련의 단계는 패턴을 구성하지 않습니다.
당신은 (프로그래머) 패턴을 찾는 자신을 찾으십니까
예. 디자인 패턴은 “예방이 치료보다 낫다”는 원칙을 구현합니다. 예정된 특정 설계 문제를 미리 발견 할 수 있다면 나중에 변경 사항을 수용하도록 대규모 재 설계를 방지 할 수 있습니다. 따라서 디자인 패턴을 미리 알고 응용 프로그램을 빌드 할 때 사용해야하는 위치를 찾아야합니다.
내가 어디에서보아야합니까?
학생이기 때문에 디자인 패턴에 영감을주는 일반적인 문제를 보지 못했을 것입니다. Head First Design Patterns 를 살펴 보는 것이 좋습니다 . 먼저 디자인 문제를 제시 한 다음 특정 패턴이 어떻게 해결 / 피할 수 있는지 보여줍니다.
답변
학교에있을 때는 디자인 패턴을 가르쳤습니다. 그리고 대부분의 프로그래밍 경력을 위해 레거시 비 객체 지향 코드로 작업했습니다. 최근 몇 년 동안 나는 그들이 좋은 생각처럼 들리기 때문에 그것들을 배우려고 노력했습니다. 그러나, 나는 책을 집어 들거나 주제에 대한 튜토리얼을 읽으려고 할 때마다 내 눈이 번쩍 들었고 실제로 그들에 대해 실질적인 것을 배우지 않았다고 고백해야합니다.
나는 그것을 공개적으로 인정했다는 것을 믿을 수 없다. 나는 아마 몇 년 동안 내가 설립 한 괴짜 신조를 잃어버린 것 같습니다.