프로그래밍 디자인 패턴을 파악할 수 없습니다

16

지난 4 년간 자바 스크립트를 사용해 왔습니다. 내 문제 해결 기술에 대해 매우 확신하며 코드 품질이 향상되고 있음을 알 수 있습니다. 커뮤니티와 최신 상태를 유지하려고 노력하고 있으며 현재 ES2015 및 React.js와 협력하고 있습니다. 그러나 프로그래밍 디자인 패턴을 전혀 파악할 수없는 것 같습니다. 나는 이것에 관한 자료를 어디서 찾을 수 있는지 알고 있으며 이미 그것에 관한 책을 읽었습니다. 나는 프로젝트 구조에 대한 결정을 내리기 위해 선임 동료들에게 의존하지만 그 작업에는 아무런 문제가 없습니다.

스스로 무언가를 시작해야 할 때마다 다음 두 가지 경로를 찾습니다. React.js와 같은 큰 라이브러리 / 프레임 워크를 사용하는 경우 커뮤니티의 활동을 복사하는 경향이 있습니다. 내가 더 작은 것에 있다면 모듈 패턴을 사용할 것입니다. 이 주제에 대해 더 잘 이해하면 더 나은 결정을 내릴 수 있지만 지금은 완전히 잃어버린 것입니다.

이것에 대한 우수한 교육을 찾아야합니까? 이 주제에 대한 멘토가 필요합니까? 난 그냥 바보 야? 이것이 정말로 이해하기 어렵습니까?

design-patterns javascript

— 아벤 수르
소스

6

제 생각에 어떤 언어는 디자인 패턴을 사용해야 할 때 다른 언어보다 더 '용서합니다'. Java 및 C #과 같은 강력한 형식의 컴파일 된 언어는 JavaScript 및 PHP와 같은 약한 형식의 스크립팅 언어보다 잘못된 디자인의 영향을받습니다. 물론 디자인 패턴은 두 가지 모두에 유용하지 않습니다.

— Matthew

3

프로젝트 규모 또한 중요한 역할을합니다.

— Matthew

2

@Matthew nitpick 필자가 Java / C #를 강력하게 입력 할 필요는 없습니다 ...

— Jared Smith

2

@JaredSmith 사실, 나는 종종 강력한 형식과 정적 형식의 차이점을 잊어 버립니다.

— Matthew

6

일반적인 패턴을 이해하려고한다면 Stop! 거기에 아무것도 없습니다! 패턴은 일반적으로 발생하는 문제에 대한 인기있는 솔루션이며 누군가 이름을 부여했습니다. 그것이 전부입니다. Java에서 이중 디스패치를 모방하기 위해 "방문자"패턴을 효과적으로 사용하는 방법을 기억하는 데 어려움 을 겪지 만 특정 패턴 을 이해하기 어려울 수 있습니다. 그러나 "방문자"를 연결하는 비밀 소스를 찾고 있다면 "데이터 전송 개체"라고 말하면 찾을 수 없습니다. 그들은 두 가지 일반적인 문제에 대한 두 가지 인기있는 해결책 일뿐입니다.

— 솔로몬 느린

34

소프트웨어 디자인 패턴은 잘 알려진 문제에 대한 잘 알려진 솔루션입니다. 패턴을 이해하고 작동 방식을 이해하고 각 패턴을 소프트웨어 디자인에 적용하는 것이 적절한 지 아는 방법을 이해하십시오.

소프트웨어 디자인 패턴을 배우는 방법은 한 번에 하나씩 연구하는 것입니다. 지속적인 교육 과정입니다. 학습 공간을 줄이려면 현재 사용중인 기술과 직접 관련된 패턴을 연구하십시오.

디자인 패턴에 대해 알아야 할 중요한 사항 :

일부 디자인 패턴은 본질적 으로 건축 적입니다. MVC 및 MVVM이 이러한 패턴의 예입니다. 이러한 패턴이 제공하는 조직적 및 구조적 이점이 필요할 때 이러한 패턴을 사용합니다.
일부 디자인 패턴은 프로그래밍 언어의 결함에 대한 해결 방법입니다. 좀 더 표현적인 프로그래밍 언어를 사용하는 경우에는 이러한 패턴이 필요하지 않지만 종종 선택하지 않아도됩니다. 의 대부분 의 GoF 패턴이 있는 이 범주에 .
패턴이 특별히 해결하도록 설계된 문제 를 해결 하려는 경우에만 소프트웨어 패턴을 사용하십시오 . 소프트웨어 패턴을 함께 연결하여 응용 프로그램을 작성하는 경우 잘못하고 있습니다.
존재하는 모든 컴퓨팅 문제에 대해 기존 소프트웨어 패턴이 없습니다. 이 경우 프로그래밍은 패턴 일치 연습 일뿐입니다.
일부 패턴은 실제로 반 패턴입니다. 이러한 패턴으로 인해 발생하는 추가 복잡성은 해당 패턴이 제공하는 이점보다 중요합니다. 패턴별로 피해야 할 패턴을 결정해야합니다.

— 로버트 하비
소스

좋은 답변이지만, 대부분의 GoF 패턴은 프로그래밍 언어의 결함에 대한 해결 방법이라는 진술에 동의하지 않습니다. 언어는 특정 문제와 해결책을 염두에두고 설계되는 경향이 있기 때문에 일부 언어는 특정 언어에 더 적합합니다.

— Polygnome

1

Gof 패턴은 20 살입니다. 대부분은 C ++에 기반을두고 있기 때문에 Java가 상속 한 문제인 C ++의 문제점을 해결하기 위해 작성되었습니다.

— Robert Harvey

이 답변의 역설은 "잘 알려진 문제"부분입니다. 이러한 "잘 알려진 문제"를 경험 한 적이 없다면 이해하기 어렵습니다.

— Fuhrmanator 2016 년

2

Java는 C ++을 기반으로 하지 않습니다 . javas 구문 은 C ++에서 영감을 얻었 지만 확실히 기반이 아닙니다. 두 언어 모두 다르게 작동합니다. Java가 하드웨어를

— 방해

4

학습에 대한 모든 사람의 접근 방식은 약간 다르며, 일반적인 접근 방식이 무엇인지 잘 모르겠지만, 자신을 "멍청한"것으로 표시하여 장애를 겪고 있다고 생각합니다.

개인적으로, 많은 사람들이 "성공적인"소프트웨어 엔지니어, 디자이너 등이 무엇을하는지에 대한 나의 관찰 결과, "경험"이라는 공통된 주제가 있습니다. 나는 이것이 당신의 "우수한 교육"이라고 믿고 당신은 아마존에서 많은 양의 책을 사고 그것을 통해 읽는 것보다 더 빨리 배울 것입니다 (나의 나쁜 습관).

예를 들어, 명령 패턴과 같은 GOF 패턴을 선택하여 원하는 언어로 구현하십시오. 그것이 당신에게주는 이점과 단점을 이해하십시오. 디자인 패턴에 대한 다양한 책이 이것을 설명하지만 실제로 그 지식을 적용하고 배우는 것이 좋습니다. 독서 자료를 할인하지 말고 목적이 있지만 IT 세계는 거의 교과서 연습이 아닙니다. 즉, IT 세계에 대한 저의 의견과 견해는 부분적으로 소프트웨어 엔지니어링 분야에서 경력을 쌓을 때의 어려움을 나타냅니다. 또한 경험이 많은 소프트웨어 개발자에게도 주요한 문제는 조바심과 그들이하는 일을 즐기는 것을 잊어 버리는 것입니다. 따라서 학습 한 내용에 시간을내어 실제로하는 일을 즐기도록 기억하십시오.

또한 다른 사람들의 실제 경험을 활용하십시오. 많은 오픈 소스 솔루션이 있으며 나쁜 것과 좋은 것이 있으며, 그로부터 배울 수 있습니다. 패턴이 어떻게 적용되었는지 살펴보고 어떻게 다르게 대처할 것인지 생각하십시오.

따라서 일반적인 조언은 접근 방식이 잘못되었다고 생각되면 변경하십시오. 자신이 이해하지 못한다고 느끼는 자료를 배우고 있다고 느끼는 주변 사람들을보고 그들이하는 일을 보거나 심지어 묻습니다.

— 황량한 행성
소스

1

정말 프로그래밍은 체스 게임과 같다고 생각합니다. 당신은 그것에 고유의 재능이있을 수 있습니다, 당신은 하루 종일 재생할 수 있지만, 체스에 관한 책을 읽지 않으면 진보를 할 수 없으며 더 중요한 것은 게임의 아름다움을 이해할 수 없다는 것입니다.

— Adrian Iftode

@AdrianIftode-동의했습니다. 언급했듯이 책, 블로그 또는 독서 자료를 할인하지는 않지만 프로그래밍 언어 / 플랫폼 / 프레임 워크 등에서 숙달을 위해 노력하는 사람들이 발견 한 일반적인 문제이며 코딩 및 실용성이 거의없는 것 같습니다. 노력하지만 막대기를 흔들 수있는 모든 책을 읽었습니다.

— 황량한 행성

@AdrianIftode 정확하지는 않습니다. 책을 읽지 않고 체스를해도 여전히 게임에 대해 많은 것을 배울 수 있습니다. 유일한 차이점은 일부 체스 마스터 경험과 생각을 그려서 배우는 것만 큼 빨리 배우지 않는다는 것입니다. 다른 한편으로, 당신이 특정 것들에 대해 생각함으로써, 당신은 체스 마스터로부터 배우는 사람들이 완전히 간과하고 당신이 유리하게 사용할 수있는 솔루션 하나 또는 둘을 우연히 발견 할 수 있습니다. 결국, 나는 두 종류의 학습이 혼합되어 최고의 혜택을 제공한다고 생각합니다. 체스뿐만 아니라 프로그래밍에서도.

— cmaster-monica reinstate 모니카

1

짧은 대답은 필요 하지 않다는 것입니다. 그것들없이 코드를 작성할 수 있습니다. Matthew가 의견에서 말했듯이 이것은 언어가 매우 유연하고 프로젝트가 더 작은 경향이있는 JavaScript에서 특히 그렇습니다. 그러나 4 년 동안 프로그래밍을 해본 적이 있다면 반복적이거나 어색하다고 느끼는 것들에 걸려 넘어지지 않았다고 믿기가 어렵습니다. 디자인 패턴을 재발견하거나 누락 한 영역입니다.

예 : JavaScript의 이벤트 시스템은 종종 당면한 작업에 적합하지 않습니다. 이벤트 스트림 을 결합하거나 변형하고 싶어하는 자신을 찾지 못했 습니까? 아니면 일련의 사건은 그 자체로 일류 가치였습니다? 중재자 및 / 또는 관찰자 패턴이 필요합니다. 양방향 데이터 바인딩이 필요하십니까? 같은 이야기.

취성 프로토 타입 계층 구조가 다운 되었습니까? 구조에 믹스 인 / 트레이 트 / 서브 클래스 팩토리 패턴.

— 자레드 스미스
소스

4

디자인 패턴을 사용하지 않고 사소한 프로그램을 작성하는 것은 사실상 불가능하며, 일반적으로 많은 공통 패턴을 사용하게됩니다. 당신이 필요로하지 않는 것은 이름으로 사용중인 패턴을 인식 할 수 있어야합니다. 코드 전체에서 사용중인 모든 디자인 패턴의 이름을 지정할 수없는 경우에도 작업 코드를 작성할 수 있습니다.

— Servy

@Servy 디자인 패턴은 추상화이며 추상화가 반드시 필요한 것은 아닙니다. 언제든지 기본 동작의 임시 일회성 구현을 반복해서 작성할 수 있습니다. 이 예에서 예를 들어 나는, 이벤트에 대한 자사의 준 수를 수동으로 모든 이해 당사자를 연결할 다음 그들에게 요구 사항 변경, 그냥 술집 / 하위를 사용하여 비교 안됐다 모든 모든 시간을 변경합니다. 서브 클래스의 경우, 많은 일회성 클래스로 모든 가능성을 수동으로 코딩 하는 것이 가능합니다 (폐기적인 경우).

— Jared Smith

1

디자인 패턴이 매우 넓어 질 수 있습니다. 더 넓은 디자인 패턴은 너무나 명백하여 디자인 패턴 (특히 특수 언어 지원이있는 경우)으로 생각조차하지 않습니다. 루프는 디자인 패턴입니다. 함수는 디자인 패턴입니다. 객체는 디자인 패턴입니다.

— Servy

@Servy 그것이 당신이 그 용어를 사용하는 방법이라면, 나는 동의하지 않지만 OP가 특별히 GOFish 패턴을 의미한다는 인상을 받았습니다.

— Jared Smith

1

@JaredSmith 디자인 패턴 은 추상화 되지 않습니다 . 구체적인 문제에 대해 반복해서 구현하더라도 여전히 패턴 입니다. 일반 Observer 클래스 를 작성하고 이를 사용하여 Observer 패턴 을 사용할 필요는 없습니다 . 등록하고 알리기 위해 구체적인 관찰자와 구체적인 방법을 쓰는 것은 여전히 패턴을 사용하고 있습니다. 어려운 것은 패턴을 인식하는 것입니다. 때때로 이름을 모르고 패턴을 사용하는 경우도 있습니다.

— Polygnome

1

경험이 풍부한 멘토를 찾으십시오. 질문 코드를보고 코드 검토를 제출 한 후 공동 작업을 시도하십시오. 이것이 코딩 기술을 향상시키는 가장 좋은 방법입니다.

특별한:

원하는 간단한 OSS 프로젝트와 협업
동일한 문제를 해결하는 두 가지 방법이있을 때는 항상 더 간단한 것을 선택하십시오
모든 종류의 이상한 오류를 자유롭게 할 수있는 부가 프로젝트를 통해 추가적인 경험을 쌓으십시오. 디자인 패턴 "어려운 길"(tm)을 배우게됩니다.

— 모토 카로 타
소스