수프에 또 다른 비유를 추가하기 위해 디자인 패턴은 Microsoft Office 도우미 인 Clippy입니다. “당신은 많은 것들에 대해 똑같은 일을하고있는 것 같습니다. 반복 자나 방문자를 제공함으로써 당신을 도울 수 있습니까?”

이러한 패턴을 잘 작성하면 이전에 여러 번 수행했던 것과 같은 방식으로 유용한 것이 언제 유용한 지, 처음 시도 할 때의 실수 및 이러한 실수를 피하기 위해 발견 된 일반적인 방법을 알 수 있습니다 . 따라서 디자인 패턴을 읽거나 메모리에서 검토 한 다음 작업을 시작합니다. 당신이 할 수없는 것은 Clippy와 마법사 만 사용하는 것입니다.

경험이없는 사람들이 실수를하고 현실을 고려하지 않는 코드를 작성할 수있는 곳은 디자인 패턴 목록이 소프트웨어의 문제를 해결하기위한 모든 가능한 접근 방식의 완전한 목록이라고 생각하고 디자인을 연결하여 코드를 디자인하려고하는 경우입니다 끝날 때까지 패턴. 야생에서 관찰 된 또 다른 열악한 전술은 디자인 패턴이 “모범 사례”라는 사실에 근거하여 디자인 패턴을 실제로 적합하지 않은 상황으로 끌어 올리는 것입니다. 아니요, 실제로 해결되는 문제 클래스에 대해서는 모범 사례 일 수도 있고 아닐 수도 있지만, 해결 하지 못한 문제 또는 더 간단한 솔루션이있을 때 불필요한 복잡성을 도입하여 해결해야하는 문제에 대해서는 최상의 사례가 아닙니다. .

물론 누군가가 YAGNI를 기반으로 패턴을 피할 수 있으며, 그것이 필요하다는 것을 깨닫고 정상적인 솔루션을 향해 모색하는 것이 가능합니다. 이는 일반적으로 처음부터 요구 사항을 실현하는 것보다 항상 나쁜 것은 아니며, 민첩한 개발에서도 완전히 예측 가능한 요구 사항이 조기에 발견되지 않으면 실망스러운 이유입니다. Java가 처음에는 일반 컨테이너를 불필요하게 복잡한 것으로 거부 한 다음 나중에 다시 볼트로 고정한다는 것을 매우 기쁘게 생각한 유일한 C ++ 프로그래머가 될 수 없었습니다.

따라서 디자인 패턴을 피하는 것을 선호하기 때문에 원칙적 으로 Iterator 를 작성하지 않는 것은 거의 실수 입니다.

UI / 데이터베이스 / 데이터 레이어에 새 필드를 추가하는 데 2 ​​~ 3 시간이 걸리며 코드에서 30 분이 걸립니다.

당신은 그것에 대해 실제로 논쟁 할 수 없습니다 :이 측정 항목에 의해 그의 디자인은 다른 것보다 훨씬 좋습니다. 그가 디자인 패턴을 피 했는지 여부 는 의심의 여지가 있지만, 디자인 할 때 올바른 “실제”문제를 고려했을 가능성이 높으며 경험상의 이점이 있으면 교과서만으로 무장 한 사람보다 자신의 직업에서 더 낫습니다. 높은 이상.

따라서 코드에서 필드를 추가하기 위해 여러 지점을 터치해야하는 패턴은 “필드를 쉽게 추가 할 수 있도록”하는 작업에 나쁜 패턴이며 이러한 패턴을 사용하지 않았다는 것을 인식했습니다. 계층 적 아키텍처는 실제로 그런 점에서 어려움을 겪을 수 있으며, 단점을 인식하지 않고 디자인 패턴을 사용하는 것은 잘못입니다.

이에 반해 디자인에 새 UI를 작성하는 데 시간이 얼마나 걸리고 계층 구조에서 시간이 얼마나 걸립니까? 프로젝트가 필드를 지속적으로 추가하는 대신 고정 된 데이터 모델을 통해 새로운 UI를 지속적으로 구축하고 배포하도록 요구했다면, 대신 그를 위해 설계했을 것입니다. 또는 또한. 그러나 “애자일을하고있다”고 슬프게도 다른 이점을 얻지 않아도된다는 의미는 아닙니다!

디자인 패턴 메뉴에서 선택하면 가장 중요한 문제에 대한 생각을 멈출 수 있습니다. 그러나 방문자를 작성할 때 인식하고 독자가 신속하게 정보를 얻는 데 도움이되도록 “방문자”를 문서화하거나 명명하는 것은 아무 것도 방해가되지 않습니다. “이것은 방문자는”작성 하는 대신 제대로 문서화하면 수석 디바이스가 제공하는 이유 끔찍한 실수입니다 – 프로그래머가 이해되지 않습니다. 방문자가 무엇인지 아는 프로그래머조차도 “이것은 방문자입니다”보다 더 많은 정보가 필요합니다.

답변