그래서 두 가지 질문을 연속적으로 요구하는 것이 이상하지만, 관련성이 높지 않고 결합하고 싶지는 않지만 스팸 질문은 아닙니다. 약속합니다!

어쨌든, 나는 최근 대학 졸업생이고, 교육은 디자인 패턴에만 영향을 미쳤습니다. 우리는 몇 가지 간단한 패턴을 구현하고 더 복잡한 패턴이 있다는 사실을 만졌으며 우리가 있다면 GoF 책을 보라는 지시를 받았습니다. 더 배우고 싶었습니다. 내 질문은 GoF 책의 패턴을 배울 가치가 있습니까? 나에게는 항상 문제를 고전적인 패턴에 맞추려고 시도하는 것이 반 직관적 인 것처럼 보였지만 분명히 책과 패턴은 이유 때문에 유명합니다. 그들이 내가 배워야 할 정도로 충분히 나타 났습니까?

다시 감사합니다!

평소와 같이

때에 따라 다르지

디자인 패턴을 인식하거나 활용할 수 있는지에 대해 얼마나 많은 OOP를 수행했는지에 따라 다릅니다.

그것은 올바르게 배운 패턴을 적용하고 망치로 잠언과 같은 견해를 가지지 않을 것인지에 대해 얼마나 훈련을 받았는지에 달려 있습니다.

반면에 ... 다섯 손가락!

당신이 심각한 OOP 작업의 몇 년을 수행 한 경우 또는 당신이 레일에 당신을 유지하기 위해 신뢰할 수있는 멘토가 또는 당신은 단지 OOP-괴상한 읽기처럼, 모든 수단으로 책을 사서 공부 이동합니다.

패턴을 아는 데 도움이되므로 사용시기와 사용하지 않을시기를 알 수 있습니다.

예, 당신은 그것들을 배워야합니다.

경험을 얻은 후에 다시 방문하는 것이 훨씬 더 합리적 이므로 알고있는 것과 비교할 수 있습니다. 일부 패턴의 경우 이것이 자신이 발견 한 것으로 밝혀 지지만 사용법, 트레이드 오프, 변형 등에 대해 더 일반적인 것을 배울 수 있습니다. 다른 사람들은 대처 한 문제를 직접 해결하고 모르는 우아한 해결책을 보여줄 수도 있습니다.

다양한 패턴의 대부분은 매우 유용하고 일반적입니다 . 다른 사람들은 인기가 없을지 모르지만 여전히 완벽하게 맞는 좁은 사용 범위를 가지고 있습니다.

읽을 가치가있는 또 하나의 이유가 있습니다 . 생각하는 법을 가르쳐 줄 것 입니다. 물론, 그것은 은색 총알이 아니지만 여전히 귀중한 영감입니다.

마지막 으로, 어떤 상황에서도 문제를 패턴이나 도구에 맞추려고하지 마십시오 . 그것은 매우 나쁘고 위험한 생각입니다! 도구가 어떻게 작동하는지 이해하고 현명하게 사용하여 문제를 해결하십시오.

잘 알고있는 도구가 많을수록 좋습니다. 때로는 도구가 문제를 직접 해결하지 않고 생각을 불러 일으킬 수 있으며, 때로는 도구를 결합하여 훌륭한 솔루션을 얻을 수 있습니다.

GOF 책은 우리가 매일 사용하는 많은 유용한 도구를 제공합니다 .

디자인 패턴에 대해 조금만 알게되면 가장 중요한 이점은 용어의 의미를 아는 것입니다. 다시 말해, 당신은 공통 어휘 를 알고 있습니다.

이것은 나에게 모든 디자인 패턴 혼란의 가장 중요한 성과이며, 특정 패턴의 이름을 사용할 수있는 공통 어휘가 생겼으며 다른 사람들은 설명하지 않고도 이야기하는 내용을 즉시 알 수 있습니다. . 패턴이 설명하는 것은 대부분의 프로그래머에게 잘 알려져 있지만 다른 사람들에게 의미를 설명하는 데 시간이 걸리므로 패턴 이름을 쉽게 알 수 있습니다.

예를 들어 방문자, 싱글 톤 및 데코레이터가 있습니다.

다시 말해, 적어도 이름과 이름에 익숙해지는 것이 좋습니다.

예, 그러나 신중하게!

예 부분 :

때로는 디자인에서 문제가 발생했습니다. 때로는 이러한 문제가 매우 흔하기 때문에 디자인 패턴을 통해 해당 문제에 대한 테스트를 거친 솔루션을 얻을 수 있습니다. 설계 패턴 학습의 주요 이점은 설계 솔루션을 훨씬 더 빨리 도출 할 수 있으며 동료가 설계 패턴 용어를 알고 있는 경우 솔루션을 훨씬 더 빨리 설명 할 수 있다는 것입니다.

신중한 부분 :

디자인 패턴은 솔루션의 성배가되어서는 안됩니다. 가장 단순한 (KISS) 솔루션이 더 바람직하며 여러 번 디자인 패턴으로 인해 작업이 더 복잡해집니다. 디자인 패턴을 배우는 경우 안티 패턴에 대해서도 배우십시오 . 나는 디자인 패턴에 반하는 오래된 사람들을 알고 있으며 코딩 경험이 많지 않지만 디자인 패턴 이론이 너무 많으면 결국 당신과 당신을 위해 더 어려워 질 수 있기 때문에 그들과 어느 정도 동의합니다. 팀.

마지막으로, 디자인 패턴을 준수하기 위해 솔루션을 적합 / 변경해야한다고 생각하지 마십시오. 반대로 디자인 패턴을 구부려 솔루션에 맞출 수 있습니다. 특정 문제에 대한 더 나은 해결책이있는 한 디자인 패턴 레시피의 모든 성분을 사용하지 않는 경우 괜찮습니다. 디자인 패턴을 솔루션의 규칙이 아니라 제안으로 생각하십시오.

후두둑에 대한 Net Objectives의 사고 방식이 가장 유익하다고 생각했습니다. GoF 책을 읽는 사람들은 종종 디자인 표기법 및 코드로 표시되는 구조가 패턴이며 이것이 항상 모양이라고 가정하기 시작합니다. 그것을 보는 다른, 더 나은 방법이 있습니다.

패턴은 다양한 문제를 해결하는 데 사용할 수있는 수식 세트가 아니라 특정 추상 수식으로 해결할 수 있는 유사한 문제 세트입니다. 이것이 의미하는 것은 디자인을 만들기 시작하기 전에 패턴이 이미 존재한다는 것입니다. 디자이너의 목표는 그것을 강요하지 않고 그것을 찾는 것입니다.

또한 많은 사람들이 패턴을보고 "아, 나는 그것을 해결했습니다. .... 어리석은 패턴을 사용하지 않았습니다." "...."은 주어진 패턴 솔루션의 구현을 거의 필연적으로 설명한다는 것입니다. 예를 들어, 기존의 레시피와 달리 함수 포인터 배열이 책임의 사슬 역할을 할 수 있습니다.

이를 염두에두고 패턴 연구에서 초점은 패턴이 아니라 문제에 초점을 두어야합니다. 패턴의 동기 요인과 이러한 요인을 해결하는 방법을 알아 봅니다. 이렇게하면 문제의 패턴을보고 간단히 지적 할 수 있습니다. 이것은 패턴이 디자인에 관해 우리에게 말하는 언어와 함께 현재 직면하고있는 다양한 어려움에 잘 맞는 디자인을 제공 할 수있게합니다.

예, 간단히 말해서 학습 패턴은 그만한 가치가있을뿐 아니라 배우지 않음으로써 자신을 제한합니다. 나는 "나에게 방문자처럼 보인다"고 말할 때 모든 동기 부여 원칙과 솔루션의 일반적인 형태를 설명하고 싶지 않습니다.

웹 사이트는 다음과 같습니다. http://www.netobjectives.com/PatternRepository/index.php?title=Main_Page

GoF가 설명하는 디자인 패턴은 OO 패러다임의 자연스러운 확장입니다. 캡슐화, 우려의 분리, DRY 원칙, 모듈화 등 OOP의 목표를 완전히 이해하지 못하면 디자인 패턴을 성공적으로 적용하는 것은 의미가 없습니다.

그러나 실제 OOP에 발을 담그고 OOP 값에 충실하려고하면 필연적으로 GoF에 설명 된 상황에 처하게되며, 이와 유사한 솔루션을 개발할 가능성이 있습니다. 비슷한 문제가 많이 해결되면 패턴이 나타나는 것을 볼 수 있습니다. 이 시점에서 책을 읽는 것이 합리적입니다. 이상적으로, 당신은 인식의 감각을 가질 것이며, 제안 된 패턴의 우아함과 청결성을 즉시 감사하게 될 것입니다. 당신은 또한 이러한 패턴 중 일부를 고려할 것입니다 (당신이 일단 알고 나면, 그들 중 많은 수가 있습니다). 또한 주어진 상황에서 특정 패턴이 적용 가능한지 여부를 잘 판단 할 수 있습니다.

그리고 여기 또 다른 경고가 있습니다. 이러한 패턴을 모두 알고 있다고해서 모든 곳에 적용해야하는 것은 아닙니다. 그들 중 일부는 매우 영리하고 사람들은 끔찍하게 부적절 할 때에도 사용하려고 유혹합니다 .Singleton 패턴이 가장 유명한 예입니다. 인스턴스 전용 제약 조건).

디자인 패턴은 설계 문제를 해결하려고합니다.

• 그들은 주로 OOP 언어를 위해 AFAIK로 만들어졌습니다.
• 함수형 프로그래밍에는 문제 중 일부가 존재하지 않습니다 (명령 패턴은 일류 함수를 만드는 방법, 전략 패턴은 고차 함수에 근사합니다 ...). 이러한 패턴은 기능이 필요없는 언어 (주로 OOP)를위한 것입니다.
• 알파벳순으로 정렬됩니다. 몇 가지 패턴은 다른 패턴의 구성이거나 아이디어는 이전에 있었던 패턴으로 구성됩니다.

나중에 기능 프로그래밍, UML, 데이터베이스 설계, 데이터 구조 및 알고리즘을 알고 난 후에 패턴을 배웠습니다. 나는 실제로 치트 시트 에이 패턴의 디자인 목록을 가져 갔으며 이미 대부분을 알고 있다고 고개를 끄덕였다. 일부는 싱글 톤 또는 "통신"패턴 (방문자, 중재자)처럼 정말 좋았습니다 ...

경험이 거의없는 디자인 패턴을 적용하는 것이 얼마나 위험한 지에 대한 몇 가지 다른 답변의 요점에 동의합니다.

그래도 적어도 GoF 책의 첫 장을 읽는 것이 좋습니다. 첫 번째 섹션에서는 패턴 디자인에 대해 소개하지만 실제로는 OO 디자인의 원칙에 대해 더 많이 다루며 이는 경험이 거의없는 경우에도 읽고 이해하는 데 도움이됩니다. (내가 기억하는 일부 주요 아이디어에는 "다양한 개념을 캡슐화", "상속 계층은 넓지 만 깊이는 없어야한다"는 내용이 포함됩니다. 이러한 패턴들에 대한 정보도 매우 중요합니다.

내 질문은 GoF 책의 패턴을 배울 가치가 있습니까?

물론! 소프트웨어 디자인 패턴뿐만 아니라 일반적인 디자인 기술을 배워야합니다. 일반적인 문제에 대한 일반적인 해결책을 배우는 것은 환상적인 시작입니다. 특히 패턴과 그 절충점을 파고 들기 시작하면.

그들이 내가 배워야 할 정도로 충분히 나타 났습니까?

Gang of Four 서적은 많은 소프트웨어 프로젝트를 검토하고 많은 개발자들이 문제를 해결하는 데 사용한 기술을 살펴보면서 개발되었습니다. 저자들은 아주 좋은 기술 몇 가지를 발견했으며 매우 불연속적인 프로젝트에 적용된 많은 것들을 발견했으며 도메인에 관계없이 더 많이 사용하도록 추상화하기 위해 노력했습니다.

문제를 고전적인 패턴에 맞추려고 시도하는 것은 항상 반 직관적 인 것처럼 보였습니다.

이것은 중요한 문제입니다. 솔루션에 맞는 문제는 없습니다. 대신, Gang of Four 디자인 패턴 책에는 각 패턴에 대한 "문제"섹션이 있으며 다른 패턴 카탈로그에는 각 패턴을 적용해야하는시기를 설명하는 유사한 섹션이 있습니다. 또한 패턴 사용의 "결과"에 대해 설명합니다. 결과를 피하려는 경우 패턴을 사용하는 것이 가장 좋은 방법은 아닙니다.