디자인 패턴이 솔루션 대신 문제가되는 경우는 언제입니까?

디자인 패턴이 솔루션 대신 문제가되는 경우는 언제입니까?

---

디자인 패턴을 사용해야하는 소프트웨어 작업을 한 적이 없습니다. Paul Graham의 Revenge of the Nerds 에세이에 따르면 디자인 패턴은 추상화가 충분하지 않다는 신호입니다.

그를 직접 인용하자면,“예를 들어, OO 세계에서는 "패턴"에 대해 많이 듣게됩니다. 이러한 패턴이 작업중인 인간 컴파일러 인 case (c)의 증거가 아닌지 궁금합니다. 프로그램에서 패턴을 보면 문제의 징후라고 생각합니다. 프로그램의 형태는 해결해야하는 문제만을 반영해야합니다. 코드의 다른 규칙은 적어도 저에게 충분히 강력하지 않은 추상화를 사용하고 있다는 신호입니다. 종종 작성해야하는 일부 매크로의 확장을 직접 생성하고 있다는 의미입니다. "

나는 모든 사람들이 디자인 패턴이 남용되고 코드에 충분한 추상화가없는 증상이라고 생각하는지 궁금했습니다.

---

패턴 자체가 문제가 아니라 개발자가 패턴을 학습 한 다음 과도하게 적용하거나 매우 부적절한 방식으로 적용 할 수 있다는 사실이라고 생각합니다.

패턴의 사용은 숙련 된 프로그래머가 자연스럽게 배우는 것입니다. 몇 가지 문제 X를 여러 번 해결했고, 어떤 접근 방식이 효과가 있는지 알고 있습니다. 당신의 기술과 경험이 적절하다고 말해주기 때문에 그 접근 방식을 사용합니다. 그것은 패턴이고 괜찮습니다.

그러나 기술이 부족한 프로그래머가 일을 수행하는 한 가지 방법을 찾고 마주 치는 모든 문제를 그 틀에 밀어 넣는 것은 다른 방법을 모르기 때문에 똑같이 가능합니다. 그것도 패턴이고 그것은 사악합니다.

---

여러분, 전체 인용문을 읽고주의 깊게 읽으십시오. 또는 더 나은 방법은 에세이를 읽으십시오.

Paul Graham은 무엇보다도 적절한 추상화 수단을 제공하지 않는 C와 유사한 언어를 비판합니다. 에세이의 범위 내에서 패턴에 대한 그의 비판은 나중에 생각하거나 그의 주요 주장에 대한 사례입니다. 그의 추론은 다음과 같습니다.

반복되는 문제를 해결하기 위해 일반적인 전략을 사용하는 것이 논리적입니다. 정말 추상적 인 언어에서는 이러한 전략을 공식화하여 라이브러리에 넣을 수 있습니다. 사용할 필요가있을 때마다 #include, 인스턴스화, 확장 등을 수행하면됩니다. 대조적으로 C와 유사한 언어는 필요한 추상화 수단을 제공하지 않습니다. 그것은 "패턴"과 같은 것이 존재한다는 사실에 의해 목격됩니다. 패턴은 라이브러리 코드로 표현할 수없는 일반적인 전략이므로 적용될 때마다 표현 적으로 작성해야합니다.

Paul Graham은 패턴 자체가 악하다고 생각하지 않습니다. 추상화 수단을 제공하는 데 부족한 언어의 증상입니다. 그런 점에서 그는 거의 확실히 옳습니다. 그 때문에 다른 언어를 사용해야하는지 여부는 물론 또 다른 논의입니다.

반면에 질문의 원래 포스터는 잘못되었습니다. 패턴은 "코드에서 추상화가 충분하지 않은 증상"이 아니라 사용자 언어로 추상화 수단이 충분하지 않은 증상입니다.

---

패턴은 실제로 작동 방식을 설명하는 방법 일뿐입니다. 그것들을 분류하는 방법입니다. 그것들을 남용하는 프로그램이 있습니까? 확실한. 패턴을 갖는 것의 가장 큰 장점은 무언가를 이것 또는 저것으로 분류함으로써 모든 사람이 같은 페이지에 있다는 것입니다 (대화되는 내용을 알 수있는 지식 수준이 있다고 가정). 10,000 줄의 코드가있는 시스템을 사용하는 경우 작업 방식을 신속하게 결정할 수 있어야합니다.

이것은 항상 패턴을 사용해야 함을 의미합니까? 그것은 분류에 강제하는 문제로 이어질 것이지만, 당신도 그것들을 부끄러워해서는 안됩니다.

---

패턴에 대한 나의 문제는 개념의 핵심에 핵심적인 거짓말이있는 것 같다. 전문 소프트웨어 디자이너가 상대적으로 드물기 때문에 관리자에게는 큰 소리로 들립니다.

문제는 그것이 사실이 아니라는 것입니다. "디자인 패턴"만으로 전문가 수준의 코드를 작성할 수 없습니다. 재봉 패턴 만 사용하여 자신 만의 전문 패션 디자이너 수준의 의류를 디자인 할 수 있습니다.

---

프로그램의 형태는 해결해야하는 문제만을 반영해야합니다.

그리고 요구 사항이 변경되고 모듈이 Facade 또는 잠재적으로 Mediator를 사용하여 추상화되지 않아 교체가 지나치게 어려워지면 어떻게 될까요?

디자인 패턴은 추상화가 충분하지 않다는 신호입니다.

모든 것을 제대로 추상화했다면 어딘가에 디자인 패턴이있을 가능성이 있습니다.

로드 할 필요가없는 매우 '무거운'개체가있는 경우 어떻게합니까? 프록시 패턴은 사용자가 영원히 기다리지 않도록합니다.

계속할 수는 있지만 충분히 말한 것 같습니다. 디자인 패턴은 올바르게 사용하면 훌륭한 도구입니다. 문제는 부적절하게 사용했을 때 발생하지만, 그래서 오용 된 패턴을 안티 패턴이라고 부릅니다.

---

저는 Paul Graham의 인용문에서이 부분이 중요하다고 생각합니다.

[...] 나는 충분히 강력하지 않은 추상화를 사용하고있다 – 종종 내가 작성해야하는 일부 매크로의 확장을 손으로 생성하고있다 [...]

당신의 언어로 이러한 추상화를 구축 할 수 있다면 (그리고 Lisp로 거의 모든 것을 할 수 있습니다. 그가 위의 말을 염두에 두었을 것입니다), 패턴으로 그들을 모델링 할 필요가 없다는 것을 보여줍니다.

그러나 모든 사람이 Lisp를 사용하는 것은 아니므로 가능한 경우에만 추상화를 구축하고 불가능한 경우 패턴을 사용할 수 있습니다. 예를 들어, 고차 함수가 없는 언어 에서는 전략 패턴을 사용하여 모델링되는 경우가 많습니다 .

그것은 당신이 그것을 어떻게 보는가의 문제인 것 같습니다. 패턴은 문제의 증상 (예 : 고차원 함수의 부족) 또는 문제의 해결책으로 볼 수 있습니다 (예 : 고차원과 같은 것을 만드는 것). 전략 패턴을 통해 가능한 기능).

---

[한숨] 사람들이 자신의 판단을 사용하기 전에 얼마나 많은 좋은 관행에 대해 폭언을해야합니까?

짧은 대답 : 객체 지향 언어로 실제 작업을 수행하는 경우 작업을 완료하기 위해 일부 GoF 디자인 패턴을 구현했을 가능성이 매우 높습니다. 당신이 이것을했는지 아닌지는 교육, 관점 및 성찰의 문제입니다. 당신이 이것을 한 적이 있거나 패턴이 존재하지 않거나 "필수"가 아니거나 "남용"된다는 것을 부정하는 것은 말도 안되는 일입니다-당신이 'hello world'보다 더 복잡한 것을 작성하지 않는 한 ;-)

왜, 얼마전 어댑터 전략이 작동하도록 싱글 톤에 대한 방문자 파사드를 구현해야했습니다.

---

디자인 패턴이라는 용어는 과부하가 걸리고 혼란 스럽습니다.

그것을 생각하는 좁은 방법이 있습니다 : 기본적으로 GoF 책에 나열된 OO 개념의 집합적인 이름 (예 : Singleton, Facade, Strategy). 이력서의 역량으로 디자인 패턴을 넣는 경우이 정의를 사용할 수 있습니다.

하나의 프로젝트에는 수십 개의 단일 객체가 쉽게 포함될 수 있습니다. 이 패턴은 인스턴스화 가능한 추상화 (예 : 매크로 또는 추상 클래스)로 코딩되는 것으로부터 분명히 이점을 얻습니다. GoF 책의 다른 많은 패턴도 마찬가지입니다.

Paul Graham의 논문은 다음과 같습니다. 디자인 패턴, 반복되는 표준 방식은 인스턴스화 가능한 추상화로 성문화되어야하며, 결과적으로 인스턴스화 가능한 추상화를 정의하는 매우 유연한 방법을 가진 언어를 사용해야합니다.

그러나 개념은 더 일반적입니다. 그가 디자인 패턴을 잘못 표현했다고 생각합니다. Christopher Alexander는 국가, 도시, 도시 및 주택의 디자인에 적용하기 위해 개념을 발명했습니다. 게임 디자이너는 Fog-of-War, Asymmetrical-Abilities 등과 같은 패턴 언어를 사용합니다.

이러한 일반적인 의미에서 디자인 패턴이 모두 인스턴스화 가능한 추상화로 코딩되어야한다는 것이 훨씬 덜 분명해집니다.

패턴 언어를 읽지 않았다면 여기 에서 범위를 확인 하십시오 . 소프트웨어 세계에서 이와 같은 것을 상상해보십시오. GoF 패턴은 ToC의 맨 아래에있을 것입니다. 구현 세부 사항입니다.

그 위에 어떤 다른 패턴을 찾을 수 있습니까?

한 챕터에는 게임 관련 패턴이있을 것 같습니다. 게임 디자인 패턴과 구현 기술을 모두 통합 할 수 있으며, 게임 루프, 월드 엔터티, 공간 해시, 높이 맵 랜드 스케이프 등과 같은 명확한 구분이 아니라고 제출합니다. 이것들은 모두 디자인 패턴입니다.

이제 한 게임 프로젝트의 범위에서 아마도 하나의 World Entity 구현 만있을 것입니다. 어떤 언어로 작업하든 누구나이 World Entity를 기본 클래스처럼 인스턴스화 할 수있는 추상화로 만들 수있을 것입니다.

그러나 패턴이 설명하는 것은이 추상화가 어떻게 형성되는지입니다. 여기에는 위치 개념이 포함되어 있고 렌더링 가능합니다. 이 디자인 패턴이 그 자체로 매크로 또는 추상 클래스로 코딩되는 것으로부터 이익을 얻을 수 있는지는 분명하지 않습니다. 패턴은 이미 추상화를 설명합니다! 세계 엔티티 구현을위한 메타 클래스를 만드시겠습니까? 모든 종류의 불경건 한 매개 변수로 세계 엔티티 클래스를 정의하는 매크로?

가상의 목차를 더 자세히 살펴보면 이러한 패턴이 게임의 일반적인 패턴에 종속되어 있음을 알 수 있습니다. 이것은 매크로 또는 추상 클래스로 코딩 할 가치가 있습니까? 아마도. 그러나 분명히 아닙니다. 우리는 게임 프레임 워크에 대해 이야기하고 있습니다. 매개 변수를 전달하고 공백을 채우는 등 컴퓨터 게임을 정의하는 것입니다. 그것은 생산적이고 재미있을 수 있지만 일을하는 유일한 방법은 아닙니다.

Erlang 플랫폼에는 서버처럼 일반적인 패턴에 대한 인스턴스화 가능한 추상화가 있습니다. 그리고 Erlang 프로젝트에는 Java 프로젝트에 Singleton이있는 것만 큼 많은 서버가 있다고 생각합니다.

그러나 특정 목적을 위해 Lisp 또는 Haskell 등에서 작업하고 서버를 작성하는 경우 때로는 서버 패턴을 따르고 인스턴스화를 시도하지 않고 좋은 오래된 함수 및 개체로 구현하는 것으로 충분합니다. 모든 것의 추상화.

모든 디자인 패턴은 소스 코드의 저수준 텍스트 패턴이 아닙니다.

---

나는 Paul Graham이 이것에 대한 큰 시간을 놓치고 있다고 생각합니다. 패턴을 사용하는 것은 패턴을 나열한 책을 골라 코드에 적용하는 것이 아닙니다. 나는 그것이 좋지 않은 선택이라는 데 동의하지만 패턴에 관한 것은 아닙니다.

디자인 패턴은 단순히 "이봐, 이것이 내가 이전에 해결 한 다른 문제와 비슷하다는 것을 알고 있습니다"를 인식하고 적절한 상황에 적용 할 수 있도록 솔루션의 좋은 추상화를 만드는 방법을 배우는 방법입니다.

사실, 합리적인 크기의 프로그램을 프로그래밍했다면 일반적으로 알려진 디자인 패턴을 사용했고 이름이 있는지 몰랐을 가능성이 있습니다. 예를 들어, "팩토리"라는 단서를 찾기 전에 오랫동안 "factory"패턴을 사용하고있었습니다. 그것이 공식적으로 무엇인지 아는 것은 내가 바퀴를 다시 발명하는 것을 막을뿐입니다.

물론 일부 잘 알려진 패턴은 약간 엉터리입니다. 싱글 톤은 확실히 의심 스럽습니다. 그러나 그것은 해결해야 할 문제를 찾고 잘하지 않는 지나치게 영리한 솔루션의 명확한 사례였습니다. 그러나 그것이 당신이 그것에 찬성하거나 반대하는 많은 문헌을 찾을 수있는 이유입니다. 사람들은 그것이 좋은 해결책이 아닐 수도 있다는 것을 인식하기 때문입니다.

그러나 패턴 전체가 추상화 를 장려하는 경우 매우 좋은 것 입니다.

---

Paul Graham의 주장은 디자인 패턴이 언어로 표현되어야한다는 것입니다. X 패턴이 있다면 그것은 사람들이 그것을하기 위해 일련의 코드를 다시 작성해야한다는 것을 의미하며, 그것을 표현하는 언어 별 방법이 있어야합니다. 이것은 언어에 내장 될 수 있으며 (어렵고 새로운 디자인 패턴을 생성 할 수 있지만) 또는 언어 내에서 자동화 할 수 있습니다 (예 : Common Lisp 매크로, 특히 이상한 방식으로 사용되는 경우 C ++ 템플릿은 거의 동일한 작업을 수행 할 수 있음). 때때로).

예를 들어, 훨씬 더 간단한 패턴 인 증분 루프를 고려해 봅시다. 시퀀스의 각 요소에 대해 무언가를해야하는 것은 매우 일반적이며 for 문에 해당하는 것이 없다면 의심 할 여지없이 공통 코딩 규칙을 채택하여이를 표현하고 누군가 (또는 일부 포섬)을 함께 패키징 할 것입니다. 다른 유사한 기본 구조와 그것에 관한 책을 쓰십시오.

마찬가지로 Factory 패턴을 사용하는 경우 언어에 Factory 기능이 포함되거나 언어 내에서 자동화 할 수 있습니다. 특히 Paul은 팩토리를 반복해서 작성하는 대신 Lisp 매크로를 작성하여 구현하기를 원합니다.

디자인 패턴을 사용할 때의 위험은 우리가 계속 입력하는 익숙한 코드 프레임 워크이므로주의 깊게 읽고 쓰지 않는 코드 덩어리가 있다는 것입니다. 불편한 점은 그것들이 우리가 계속해서 타이핑해야하는 코드이고, 재 작성이 정말로 자동화되어야한다는 느낌입니다.

패턴이 GoF가 말한 것처럼 언어를 사용하는 데 필수적인 부분인지 아니면 PG가 말했듯이 추상화 할 수 있는지 여부는 근본적으로 경험적 질문이며 패턴 자체가 불필요한 언어를 찾고 패턴이 있는지 관찰하여 해결할 수 있습니다. 정말 새로운 패턴이 필요합니다.

---

디자인 패턴은 다음과 같이 정의됩니다 (위키피디아에서 왔지만 일부 책에서도 똑같이 읽었습니다)

소프트웨어 엔지니어링에서 디자인 패턴은 소프트웨어 디자인에서 일반적으로 발생하는 문제에 대한 일반적인 재사용 가능한 솔루션입니다. 디자인 패턴은 코드로 직접 변환 할 수있는 완성 된 디자인이 아닙니다. 다양한 상황에서 사용할 수있는 문제를 해결하는 방법에 대한 설명 또는 템플릿입니다.

If you look at applying patterns right from the offset without getting into the problem domain extensively can lead to problems. Use design patterns as a guide or more so as a tip/hint to solve a problem. Forcefully applied design pattern will surely not give a solution thats abstract enough. It is often seen that in Enterprise software a variant or a combination of a few design patterns are used..kind of hybrids. If you say you have never used design patterns then you would be happy to know that something like a foreach loop is actually an interator pattern and you can hunt for more obvious implementations near you!

---

In a nutshell patterns are just formalized ways of solving common tasks in various languages. As such there were "design patterns" even before someone coined the term. For every language there are "best practices" and design patterns are really just that - a set of best practices for problems that occur on a regular basis.

One of the main benefits of labeling the patterns is that the shared terminology allows us to talk about abstract concepts.

Obviously design patterns can be misapplied or overused in any given context, but I really fail to see how design patterns as a concept can be a problem.

---

When I programmed in LISP I didn't use GoF design patterns at all, it just was not applicable for the programs that I was writing. Now I'm programming in C# and run across situations all the time where a design pattern actually simplifies the program being written.

---

There is a time and place for everything. I've seen code with too many patterns, which would agree with your point, but also with not enough patterns, making the code difficult to maintain and error prone when making changes.

Generalizing something like this is going to be logically flawed, but if you rephrase your question to something along the lines of "can there be too many patterns in code that is symptomatic of a bigger problem, that is, insufficient levels of abstraction" then the answer would be yes. Is it always the case? No.

---

There are a lot of maxims we use (and which are common around SO) that, if you trace them back to the source, originally were asserted with reservations; as in " ... when you are developing using ..." This is one of those cases. Patterns fit well when you are doing OOP. YMMV when you are in another paradigm.

"Refactoring" is another similar case.

When I'm writing SQL, the "patterns" part of my brain switches off.

Note in your quotation: "I'm generating by hand the expansions of some macro that I need to write.". So he recognizes patterns and abstracts them into a macro - he doesn't recode it another way. Just good-ol' DRY. It's not the patterns, it's failing to do the right thing with the ones we find. I'd say his comment could go into any wiki entry expanding on the virtues of DRY, and how to own them. GoF would concur completely - recognize the desgin patterns, then use what you know about them to implement (or refactor) them appropriately.

---

During the design phase of my programs, I often break down the problem first, and once I have it broken down then I can easily start to recognize patterns inherent within the design. At that point, I can begin to apply well-known design patterns so that when it comes time to communicate or implement the design, I have a common language I can use for communication, and hopefully I can re-use some generic objects that were previously implemented during the implementation of a similar pattern.

Often times, when design patterns are applied incorrectly, it's because the process happens in reverse. Programmer Joe (my apologies to those of you named Joe) reads a book on Design Patterns, and says "Ok, I understand Design Pattern X, now how can I apply it to my application?" This is wrong.

Design patterns can be a mighty weapon, but like anything else, they should be used appropriately, and the programmer should always be prepared to incorporate some original thought into his design, as well.

---

I think that sometimes when you learn a pattern, you don't just learn the pattern. But you aquire a new view at the problem domain which you might not have had before. And maybe its exactly what you wanted.

Without context for the "problem" we can't say if design patterns are the solution or not.

---

There is never a need to use design patterns—you can always write code that ignores everything that has been learned about coding up to now—it may even work. But design patterns can make things easier, giving you a shared language for discussing design.

Diesign patterns don't represent too little abstraction—they are an attempt to increase the level of abstraction. You can say "this bit is a Visitor" rather than "here is some code that recursively traverses a tree of objects, performing on operation on them."

---

Patterns are the problem if they aren't a solution. By that I mean: if a pattern is introduced for the pattern's sake and not to solve a real, existing design problem in the application, it's likely to cause issues rather than solve or prevent them.
I keep telling people here at work that the Gang of Four book (Design Patterns: Elements of Reusable Object-Oriented Software) is a reference, not a handbook for good design.

---

Yes, pg is right there. If you see similar code throughout your application, it means that you are missing an abstraction of that code. Less code is better.

Here is another article on the subject: http://blog.plover.com/prog/design-patterns.html

---

I would rather work with too many patterns than none at all. That said, the proper balance is of course the goal.

---

That sentence makes no sense: design patterns are a sign of not enough abstraction As design patters are an abstraction! Following the answers here I agree that programming languages should have a way to express design patterns. However that is obviously not possible for every situation.

---

I recall an interview with one of the GoF where someone asked about the common claim that design patterns are tools to replace features which are missing from a language. The author argued that A) any language has design patterns (not the same ones) since design patterns are tools built to work around language idiosynchrasies and B) it is not feasible to get rid of their need by adding more features to a language.

---

Design Patterns are solutions for common problems.

But first, you need to know what or where is the problem. And that's the point where people fail to use the patterns correctly.

---

I've also not yet found a use for GoF "Design Patterns" in my code. The coderati appears to have latched on to the GoF book, and it is now expected in the majority of companies that you know them and apply them. Just today I had an interview and was asked which patterns I knew and had used, and how I would apply them to an enterprise app for a major bank.

The generic idea of learning from our previous projects obviously makes sense. What doesn't make sense is the hype and cult around the specific GoF patterns, people mistaking them for good-coding practice, and being expected to love and embrace them in order to be called a competent developer.

So to answer your question, I'd say the GoF idea of design patterns is misunderstood and overused by most. We need to mature into a higher-level use of design patterns as a general learning tool that applies to the way we learn and refine OO--not just as 20 cookie-cutter ideas to memorize and impose on programs. There is no silver bullet.

---

Programming languages, like spoken ones, provide you with the vocabulary to say whatever you want. Patterns only describe a way to say things that allows people to know what you're talking about at a higher level.

If you'll indulge me in a metaphor: Writing music is a common 'problem' and music is often (obviously not always) loosely composed as some kind of variation on the following:

verse chorus verse chorus verse chorus chorus

Which, indeed is a 'pattern'. You still need to write the song though and not every song written will work well using this pattern.

The point I'm trying to get at is that patterns aren't a plug-play-done solution for programming, or music. They're a guideline to get you started and a springboard from which you can make something that suits your need.

ReferenceURL : https://stackoverflow.com/questions/466365/when-are-design-patterns-the-problem-instead-of-the-solution