디자인 패턴에 관한 4-5 권의 책을 읽었지만 여전히 디자인 패턴의 중간 수준에 가깝다고 느끼지 않습니까?
디자인 패턴을 어떻게 공부해야합니까?
디자인 패턴에 대한 좋은 책이 있습니까?
나는 이것이 경험과 함께 올 것임을 알고 있지만 이것을 마스터 할 수있는 방법이 있어야합니까?
디자인 패턴에 관한 4-5 권의 책을 읽었지만 여전히 디자인 패턴의 중간 수준에 가깝다고 느끼지 않습니까?
디자인 패턴을 어떻게 공부해야합니까?
디자인 패턴에 대한 좋은 책이 있습니까?
나는 이것이 경험과 함께 올 것임을 알고 있지만 이것을 마스터 할 수있는 방법이 있어야합니까?
답변:
가장 좋은 방법은 코딩을 시작하는 것입니다. 디자인 패턴은 단지 읽기에 적용하기 어려운 훌륭한 개념입니다. 온라인에서 찾은 샘플 구현을 살펴보고 주변에 구축하십시오.
훌륭한 자료는 Data & Object Factory 페이지입니다. 그것들은 패턴을 다루고 개념적 및 실제적인 예를 제공합니다. 참조 자료도 훌륭합니다.
나는 3 권의 책을 읽었지만 OReilly의 Head First Design Patterns 를 읽을 때까지 패턴을 잘 이해하지 못했습니다 . 이 책은 내 눈을 뜨고 실제로 잘 설명했다.
그런 오래된 질문에 대한 내 센트
어떤 사람들은 이미 연습과 리팩토링을 언급했습니다. 패턴에 대해 배우는 올바른 순서는 다음과 같습니다.
대부분의 사람들은 1을 무시하고 많은 사람들은 2를 할 수 있다고 믿으며 거의 모든 사람이 3을 향해 똑바로갑니다.
저에게 소프트웨어 기술을 향상시키는 열쇠는 TDD를 배우는 것이 었습니다. 고통스럽고 느린 코딩은 오랜 시간이 걸릴 수 있지만 테스트를 먼저 작성하면 코드에 대해 많은 생각을 할 수 있습니다. 강의실에 너무 많은 보일러 플레이트가 필요하거나 쉽게 고장 나면 악취가 아주 빨리 나옵니다.
TDD의 주요 이점은 코드 리팩토링에 대한 두려움을 잃고 매우 독립적이며 응집력있는 클래스를 작성해야한다는 것입니다. 좋은 테스트가 없으면 깨지지 않은 것을 만지기가 너무 고통 스럽습니다. 안전망을 사용하면 코드의 급격한 변화를 경험할 수 있습니다. 바로 연습에서 배우기 시작할 수있는 순간입니다.
이제 패턴에 관한 책을 읽어야 할 시점이 왔습니다. 제 생각에는 너무 열심히 노력하는 것은 시간 낭비입니다. 비슷한 것을하거나 기존 코드에 적용 할 수 있음을 알면 패턴을 실제로 잘 이해했습니다. 안전 테스트 나 리팩토링 습관이 없다면 새로운 프로젝트가 나올 때까지 기다렸을 것입니다. 새로운 프로젝트에서 패턴을 사용하는 문제는 작업 코드에 어떤 영향을 미치거나 변경하는지 알 수 없다는 것입니다. 코드를 리팩터링 한 후에 만 소프트웨어 패턴을 이해했지만 코드에 새로운 코드를 도입 한 적이 없었습니다.
Derek Banas는 내가 좋아하는 패턴을 제거하기 위해 YouTube 튜토리얼을 만들었습니다.
http://www.youtube.com/playlist?list=PLF206E906175C7E07
시간이 조금 단축 될 수 있지만, 그의 타이밍과 프리젠 테이션은 배우기가 매우 즐겁습니다.
연습, 연습, 연습.
몇 년 동안 첼로 연주에 대해 읽을 수 있지만 여전히 악기에 활을 넣고 음악과 같은 것을 만들 수는 없습니다.
디자인 패턴은 높은 수준의 문제로 가장 잘 인식됩니다. 유용한 것으로 인식하는 데 필요한 경험이있는 경우에만 관련이 있습니다. 그것들이 유용하다는 것을 인식하는 것이 좋지만, 그들이 적용되거나 적용되는 상황을 보지 않으면 그들의 진정한 가치를 이해하는 것은 거의 불가능합니다.
다른 코드에서 디자인 패턴을 인식하거나 디자인 단계에서 패턴과 잘 맞는 문제를 인식 할 때 유용합니다. 그런 다음 공식적인 패턴을 조사하고 문제를 조사하고 그들 사이의 델타가 무엇인지, 패턴과 문제에 대해 무엇을 말하는지를 결정하십시오.
실제로 코딩과 동일합니다. K & R은 C의 "성경"일지 모르지만, 그것을 여러 번 읽는다는 것은 단지 하나의 실용적인 경험을 제공하지는 않습니다. 경험에 대한 대체품은 없습니다.
연습 연습 연습. 나는 4-5 권의 책이 약간의 연습을하지 않으면 서 과도한 독서 운동이라고 생각합니다. 이 작업을 수행하는 가장 좋은 방법 은 패턴을 사용 하여 현재 프로젝트 를 리팩토링하는 것 입니다. 또는 현재 진행중인 프로젝트가없는 경우 자신 만의 방식으로 패턴을 리팩토링 해보십시오. .
그들이 해결 한 문제로 어려움을 겪지 않으면 완전히 감사 할 수 없습니다. 그리고 그것들은은 총알이 아니라는 것을 명심하십시오-암기 할 필요가 없으며 즉시 적용하기 위해 강요하지 않아도됩니다. 내 두 센트 ..
다음과 같은 질문을 해보십시오.
그들은 무엇을합니까?
그들은 무엇을 분리 / 결합합니까?
언제 사용해야합니까?
언제 사용해서는 안됩니까?
어떤 누락 된 언어 기능으로 인해 사라지게됩니까?
어떤 기술 부채를 사용하여 발생합니까?
작업을 수행하는 더 간단한 방법이 있습니까?
하나는 그들이 해결 한 문제를 이해하고 다른 하나는 문제가 어떻게 구현되었는지 이해할 때까지 일부 패턴의 이점을 이해하거나 이해하기가 조금 어렵다는 것을 알게되었습니다.
GOF 및 POSA 서적 외에는 실제로 읽지 않았으므로 다른 권장 사항을 줄 수 없습니다. 실제로 문제 영역을 이해해야하며 경험이 많은 많은 개발자가 패턴의 이점을 이해하지 못할 수 있다고 생각합니다. 이것은 그들에게 조금도 아닙니다. 나쁜 대안을 먼저 사용해야 할 때 좋은 해결책을 받아들이고 이해하고 평가하는 것이 훨씬 쉽습니다.
행운을 빕니다
좋은 예가 많이 있습니다. 하나를 추가하고 싶습니다.
그들을 오용하십시오. 의도적으로 그렇게 할 필요는 없으며, 초기 Design-Pattern-fit에 적용하려고 할 때 발생합니다. 그 동안 여러분이 보게 될 모든 단일 문제는 정확히 하나의 디자인 패턴에 맞는 것처럼 보입니다. 종종 문제가 어떤 이유로 같은 디자인 패턴에 맞는 것처럼 보입니다 (싱글턴이 그 주요 후보입니다).
패턴을 적용하면 좋을 것입니다. 그리고 몇 달 후에 코드에서 무언가를 변경하고 특정 패턴을 사용하는 것이 그렇게 똑똑하지 않다는 것을 알 수 있습니다. 왜냐하면 자신을 구석에 코딩하고 다시 리팩터링해야하기 때문입니다.
물론, 그것은 실제로 할 일과 21 일 답변을 배우지는 않지만 제 경험상 문제에 대한 좋은 통찰력을 줄 가능성이 가장 큽니다.
Allan Shalloway의 "Design Patterns Explained"를 읽었습니까?
이 책은 패턴의 카탈로그가 많지 않기 때문에 다른 디자인 패턴 책과는 매우 다르지만 주로 패턴에 쉽게 맵핑되는 문제점 공간을 분해하는 방법을 제시합니다.
문제는 일반적인 부분과 다양한 부분으로 나눌 수 있습니다. 이 작업이 완료되면 일반적인 사항과 인터페이스 및 구현에 따라 다른 사항을 매핑합니다. 본질적으로 많은 패턴이이 "패턴"에 속합니다.
예를 들어 전략 패턴에서 공통 사항은 전략의 맥락으로 표현되고 변수 부분은 구체적인 전략으로 표현됩니다.
나는이 책이 전화 번호부를 읽는 것과 같은 정도의 흥분을 가진 다른 패턴 책 들과는 대조적으로 자극적 인 생각을하는 것을 발견했다.
책의 경우, Design Patterns Explained 및 Head First Design patterns를 권장 합니다 . 이러한 패턴을 실제로 배우려면 기존 코드를 살펴 봐야합니다. 이미 사용중인 패턴을 찾으십시오. 코드 냄새 와 어떤 패턴으로 해결할 수 있는지 살펴보십시오 .
나는 몇몇 디자인 패턴 토론 그룹 ( 우리 사이트 )을 이끌었고 5 개 또는 6 개의 패턴 책을 읽었습니다. Head First Design Patterns 책으로 시작하여 토론 그룹에 참석하거나 시작하는 것이 좋습니다. Head First 책은 처음에는 약간 Hasboro로 보일지 모르지만 대부분의 사람들은 한 두 장을 읽은 후 그것을 좋아합니다.
패턴 순서에 대한 뛰어난 자료 -Joshua Kereivisky의 학습 패턴 디자인 패턴 을 사용하여 토론 그룹에 도움을주십시오. 경험상 내가 주문에 제안한 한 가지 변화는 전략을 우선시하는 것입니다. 오늘날 대부분의 개발자들은 Factory의 좋은 또는 나쁜 화신을 경험 했으므로 Factory로 시작하면 패턴에 대해 많은 대화와 혼란을 초래할 수 있습니다. 첫 만남.
나는 최고의 책에 대해 모른다. 그러나 순수 주의자들은 디자인 패턴 : 재사용 가능한 객체 지향 소프트웨어의 요소 .
개인적으로 좋아하는 한 O'Reilly가 출판 한 Head First Design Patterns가 마음 에 듭니다. 그것은 나에게 호소하는 대화 음성으로 작성되었습니다. 읽을 때 소스 코드를 동시에 검토하여 읽은 내용에 적용되는지 확인했습니다. 그렇다면 리팩토링했습니다. 이것이 내가 책임의 사슬을 배운 방법입니다.
연습-연습-연습.
디자인 패턴을 배운 방식은 정말 끔찍한 소프트웨어를 많이 작성하는 것입니다. 내가 12 살쯤되었을 때, 무엇이 좋았는지 나쁜 것인지 전혀 모른다. 방금 스파게티 코드를 썼습니다. 앞으로 10 년 동안 나는 실수를 통해 배웠습니다. 나는 효과가있는 것과 그렇지 않은 것을 발견했다. 나는 대부분의 일반적인 디자인 패턴을 독립적으로 발명했기 때문에 디자인 패턴이 무엇인지 처음 들었을 때, 그 패턴에 대해 알게되어 매우 기뻤으며, 이미 직관적으로 알고있는 것들에 대한 이름 모음 일 뿐이라는 것에 매우 실망했습니다. (10 년 동안 C ++을 가르치는 것에 대한 농담은 실제로 농담이 아닙니다)
이야기의 도덕 : 많은 코드를 작성하십시오. 다른 사람들이 말했듯이 연습, 연습, 연습. 현재 디자인이 나쁜 이유를 이해하고 더 나은 방법을 찾기 전까지는 다양한 디자인 패턴을 적용 할 위치를 잘 모를 것입니다. 디자인 패턴 북은 이해하지 못하는 문제에 대한 붙여 넣기 솔루션이 아니라 다른 개발자와 논의 할 수있는 세련된 솔루션과 일반적인 용어를 제공해야합니다.
디자인 패턴을 읽고 코딩을 연습한다는 개념은 실제로 IMO에 도움이되지 않습니다. 이 책들을 읽을 때 1. 특정 디자인 패턴으로 해결되는 기본 문제를 찾아보십시오. Creational Patterns로 시작하는 것이 가장 좋습니다. 2. 과거에 코드를 작성했다고 확신합니다. 디자인 패턴이 솔루션을 제공하는 것과 동일한 문제에 직면했는지 분석하십시오. 3. 코드를 재 설계 / 리팩토링하거나 새로 시작하십시오.
자원에 대해 다음을 확인할 수 있습니다
1은 빠른 시작, 2는 심층 학습입니다. 3은 2에서 배운 내용을 엔터프라이즈 소프트웨어에 적합하게 설명하거나 생각하게합니다.
내 2 센트 ...
디자인 패턴을 연구하는 것도 어렵다고 생각합니다. OOP 및 중대형 응용 프로그램 개발 경험에 대해 더 많이 알아야합니다. 저에게는 토론을하기 위해 개발자 그룹으로 공부하고 있습니다. 패턴 학습을 완료 한 패턴 을 학습하는 학습 안내서를 따릅니다 . C #과 JavaScript 개발자가 함께 참여합니다. C # 개발자가 JavaScript로 코드를 작성하고 JavaScript 개발자가 C # 코드에 대해 동일한 작업을 수행한다는 것은 멋진 일입니다. 회의를 마치고 나면 집에서 몇 권의 책을 조사하고 읽고 검토합니다. 더 많이 이해하고 기억하는 더 좋은 방법은 http://tech.wowkhmer.com/category/Design-Patterns.aspx 에서 C #과 JavaScript의 예제로 블로그를 작성하는 것 입니다.
각 디자인 패턴으로 가기 전에 먼저 패턴 이름을 이해하십시오. 또한 누군가가 개념을 알고 있다면 프로그래밍뿐만 아니라 읽기 세계에서 하나의 예를 설명하고 제시하십시오.
예를 들면 다음과 같습니다.
공장 방법 :
세계를 읽으십시오 : 나는 단지 5 달러, 10 달러 또는 20 달러의 돈을주고 그것이 어떻게 생산되는지에 대해 전혀 알지 못하고 피자를 다시 생산할 것입니다. 작거나 중간 또는 큰 피자는 돈 입력에 의존하여 먹거나 무엇이든 할 수 있습니다.
프로그래밍 : 클라이언트는 매개 변수 값 $ 5, $ 10 또는 $ 20을 팩토리 메소드로 전달하면 피자 오브젝트를 다시 리턴합니다. 따라서 클라이언트는 처리 방법을 모른 채 해당 객체를 사용할 수 있습니다.
이것이 당신을 도울 수 있는지 잘 모르겠습니다. 회의에 참여하는 사람들의 지식 수준에 따라 다릅니다.
또 다른 디자인 변경으로 인해 코드를 10 번 수정 한 후 머리카락을 뽑는 개발자로서 발생한 문제 중 일부를 조사해야한다고 생각합니다. 아마도 많은 재 작업과 고통이 있다고 생각한 프로젝트 목록이있을 것입니다.
이 목록에서 디자인 패턴이 해결하려는 시나리오를 도출 할 수 있습니다. 다른 데이터 세트에 대해 동일한 일련의 작업을 수행해야하는 시간이 있었습니까? 응용 프로그램에 대한 향후 기능을 제공 할 수 있어야하지만 기존 클래스에 대한 모든 논리를 다시 작성하지 않으려 고합니까? 이러한 시나리오부터 시작하여 패턴 카탈로그 및 해결해야 할 각각의 문제로 돌아가십시오. GoF와 프로젝트 라이브러리간에 일치하는 항목이있을 수 있습니다.