프로그래밍에서 패턴과 반 패턴에 대한 집착을 누군가가 설명 할 수 있습니까? 패턴의 의미를 전혀 모르기 때문에 묻습니다. 프로그래밍 작업에 직면했을 때 약간의 문제에 대해 생각하고 관련이 있다고 생각되는 일부 데이터 구조를 작성하고 솔루션을 프로토 타입하고 일부 모듈을 분리하여 반복하십시오. 그 과정에서 나는 "아, 여기 FunkyLookyTastic 패턴이 필요하다"고 생각하지 않습니다.
프로그래밍에서 패턴과 반 패턴에 대한 집착을 누군가가 설명 할 수 있습니까? 패턴의 의미를 전혀 모르기 때문에 묻습니다. 프로그래밍 작업에 직면했을 때 약간의 문제에 대해 생각하고 관련이 있다고 생각되는 일부 데이터 구조를 작성하고 솔루션을 프로토 타입하고 일부 모듈을 분리하여 반복하십시오. 그 과정에서 나는 "아, 여기 FunkyLookyTastic 패턴이 필요하다"고 생각하지 않습니다.
답변:
패턴은 일반적인 유형의 문제를 해결하기위한 일반적인 접근 방식입니다. 더 이상 아무것도 없습니다. 이를 이해하고 이해함으로써 다른 사람들의 경험을 활용하여 잘 작동하는 것으로 보이는 솔루션의 종류로 안내하고 과거에 발생한 함정을 피하며 다른 사람에게 친숙한 용어를 사용하여 솔루션에 대해 토론 할 수 있습니다. 그 패턴을 알아라.
물론 패턴을 명시 적으로 사용하지 않고 훌륭한 솔루션을 만들 수 있으며 특정 문제에 실제로 맞지 않는 패턴을 적용하여 나쁜 솔루션을 만들 수도 있습니다. 나는 당신이 관찰하는 "강박 관념"이 일반적으로 개념을 발견 한 사람들로부터 온 것이라고 생각하며, 그것이 실제로보다 강력하다고 생각합니다. 대부분의 사람들은 마법의 총알이 아닌 유용한 도구 인 자신이 무엇인지 빠르게 인식합니다.
반대로 안티 패턴은 일반적으로 코드 품질을 저하시키는 경향이있는 행동입니다. 다시 말하지만, 그러한 행동을 피하고 다른 사람들에게서 그것을 관찰 할 때 (이론적 인 주장으로) 정정하려고 노력할 수 있도록 이들 중 일부를 알고 이해하는 것이 유용합니다. 어떤 사람들은 패턴의 남용을 반 패턴으로 묘사 할 것입니다.
패턴은 요리 책에있는 프로그래머의 증류 된 지식이며, 프로그래머가 의사 소통하는 데 유용한 방법입니다.
다른 답변에서 알 수 있듯이 패턴은 실제로 일반적인 문제에 대한 일반적인 솔루션입니다. 이점은 코딩을 시작하기 전에 기존 패턴을 사용하여 더 나은 솔루션을 얻거나 가능한 함정을 발견 할 수 있다는 것입니다.
다른 이점은 코드에 대해 누군가와 이야기 할 때입니다. 패턴은 긴 설명을 몇 단어로 압축하는 또 다른 유형의 전문 용어입니다. 패턴을 참조하지 않고 "공장에서 관찰자를 추가했다"고 설명해보십시오. 할 수 있지만 시간이 오래 걸립니다.
대부분의 개발자는 새로운 패러다임이나 방법론에 대해 울부 짖습니다. 디자인 패턴에 대해 처음 들었을 때 나는 그렇게했습니다. 디자인 패턴은 이름에서 제안하는 것입니다. 클래스를 만들고 예측 가능한 방식으로 동작과 상호 작용을 모델링하기위한 디자인 또는 템플릿
주택을 살펴보십시오. 그들은 몇 가지 유사점이 있습니다. 모든 집에는 거실, 주방, 침실, 욕실, 화장실이 있습니다. 아무도 화장실없이 집을 짓지 않을 것입니다. 아파트에는 방갈로와 다른 패턴이 있습니다. 성은 완전히 다른 패턴을 가지고 있습니다. 옷도 패턴이 있습니다. 재킷과 정장 셔츠는 모두 기본 디자인이 동일하지만 동작이 다릅니다. 인터뷰를 위해 카우보이 재킷을 입지 않습니다. 마찬가지로 클래스와 해당 동작은 동작 및 디자인에 따라 그룹화 할 수 있습니다. 동작의 공통 요소를 보면 클래스의 디자인 패턴이 제공됩니다.
재사용 성과 확장 성이 주요 관심사 인 경우에만 이해하는 디자인 패턴이 중요합니다. 작은 응용 프로그램 (예 : 10 개 미만의 클래스)을 만들면 전혀 필요하지 않을 수 있습니다. 그러나 대규모 프로젝트, 특히 대규모 팀이 작업하고 유지 보수 및 기능 추가주기가 긴 프로젝트는 패턴이 필요합니다. 대규모 프로젝트에서는 옵션이 아닙니다.
패턴에 대한 온라인 자습서를 살펴보십시오. Wikipedia에는 좋은 기사가 있습니다. 이 사이트도 좋습니다 : http://sourcemaking.com/ . 숙련 된 프로그래머라면 몇 가지 패턴을 발견했을 수도 있고 특정 이름으로 알지 못하고 비슷한 것을 구현했을 수도 있습니다.
그들을 완전히 무시하지 마십시오! 지금이 아니라면 나중에 유용 할 것입니다. 열린 마음으로 디자인 패턴에 접근하는 열쇠는 "디자인 패턴을 사용하지 않으면 어떻게됩니까?" 패턴은 "치료"를 의미하지 않습니다 (문제의 치료제로 사용할 수는 있지만). 오히려, 그들은 "예방이 치료보다 낫다"라는 말을 구현합니다.
마찬가지로, 나는 당신이 그것을 사용할 작은 구실을 볼 때마다 언제 어디서나 패턴을 구현하는 것에 대한 집착에 대해주의 할 것입니다. DP가 없으면 프로젝트가 완전한 재앙이 될 것이라고 건축가가 확신 한 한 프로젝트 에서이 문제에 직면했습니다. 우리는 엔지니어들이 디자인을 살펴 보는 그룹 회의를 가졌으며 그가 추천 한 많은 패턴이 "아름다운 패턴을 보아라"는 것 외에는 전혀 쓸모가 없을 것이라고 지적했습니다. 패턴이 필요한 곳의 수를 줄이기 위해 많은 설득력과 협상이 필요했습니다.
응답 한 사람들은 일반적으로 생각한대로 "패턴 기반 프로그래밍"측면에서 정확합니다. 나는 내가하고있는 일과 더 관련이 있다고 생각하는 약간 다른 정의를 가지고 있으며, "패턴 기반 프로그래밍"을 사용하여 계획 방식이 아닌 플러그인 방식을 설명하는 경향이있다.
CMS 클라우드 플러그인 및 전자 상거래 플러그인 인 jQuery 플러그인을 프로그래밍하기 때문에 이러한 관점에서 "패턴 기반 프로그래밍"이란 핵심 기술과 사용 사례가 무엇인지, 통계적으로 가장 관련성이 높은 것을 살펴 보는 것을 의미합니다. 플러그인은 특히 패턴 기반이어야하므로 프로그래밍 컨텍스트에 잘 맞습니다.
그러나 여러 프로젝트에서 유효한 사용 사례를 본 후에 패턴을 적용하여 통계적으로 재사용 할 수 있도록하는 것이 가장 좋습니다.