소프트웨어 디자인 패턴을 사용하지 않으면 어떻게됩니까? [닫은]

17

폐쇄되었습니다 . 이 질문은 더 집중되어야 합니다. 현재 답변을받지 않습니다.

이 질문을 개선하고 싶습니까? 이 게시물 을 편집 하여 한 가지 문제에만 집중할 수 있도록 질문을 업데이트하십시오 .

휴일 육년 전 .

소프트웨어 디자인 패턴을 사용하지 않으면 어떤 문제가 발생할 수 있습니까? 표준 객체 지향 기술을 사용하여 디자인에 접근하는 문제에 대해 알려줄 수 있습니까?

design-patterns

— 학생
소스

24

상당수의 소프트웨어 디자인 패턴이 상당히 분명합니다. 당신은 당신이 그들을 사용하지 않도록 확실히 잘 알고 있어야 할 것입니다-아마 당신이 그들을 잘 사용할만큼 충분히!

— James McLeod

18

@JamesMcLeod에 대한 측면으로서, 많은 "디자인 패턴"은 매우 명백하며 모든 사람들이 어쨌든 할 것입니다. 그렇다면 왜 우리는 그들에게 이름을 부여합니까? 의사 소통을 위해. "X 패턴을 사용하고 있습니다."는 상대방이 "오 그래! 변수를 호출 한 것 외에는 그 작업을 수행했습니다."

— Phoshi

6

@AJMansfield 내가 본 최악의 코드 중 일부는 디자인 패턴에 대한 과도한 열정과 관련이 있습니다.

— Erik Reppen

5

@ErikReppen은 디자인 패턴의 남용에 대한 책임은 그 사람에게 귀속되어야합니다. 내 관점에서 볼 때, 핵심 문제는 디자인 패턴 자체가 아니라 지나치게 일반화 (부분적으로 아키텍처 감독 부족으로 인해) 및 과도 엔지니어링 (때때로위원회의 엔지니어)에 의한 것입니다.

— rwong

5

"디자인 패턴"은 기술이 아닌 어휘집입니다.

— Kaz Dragon

76

요점이 없습니다.

디자인 패턴은 세계에 구조적 패턴이 존재하는 것처럼 소프트웨어 디자인을 수행 할 때 본질적으로 존재합니다. 사물의 이름을 모르더라도 결국 특정 물리적 구조가 특정 문제에 적합하다는 것을 알게 될 것입니다. 나무 / 금속 막대 등의 삼각형 모양은 매우 안정적인 구조이지만 평면에만 있습니다. 사각형 벽돌은 둥근 벽돌보다 장점이 있습니다 ...

마찬가지로 특정 소프트웨어 구조는 독창적이거나 최적입니다. 당신은 그 이름 을 알지 못하더라도 결국 그들을 찾아서 사용할 것입니다. 이것이 디자인 패턴의 핵심입니다. 숙련 된 프로그래머가 알고 사용하는 구조의 이름 입니다. 프로그래머에게 훨씬 더 균일하고 간결하게 의사 소통 할 수있는 기능을 제공합니다. 또한 프로그래머는 패턴의 개념을보다 의식적으로 생각할 수 있습니다.

그래서 내가하려고하는 두 가지 핵심 사항 :

당신은 할 수 없는 디자인 패턴을 사용합니다.
사용중인 항목의 이름을 모르면 팀에서 작업하기가 어려워집니다.

— 텔라 스틴
소스

12

+1 : 물론 맞습니다. 디자인 패턴이 알려 지거나 대중화되기 전에 OO 개발을 시작했습니다. 그렇습니다. 우리는 팩토리, 싱글 톤과 같은 것을 발명했습니다 . 전략 패턴과 같이 밝은 빛으로 보이게 만들었습니다. 요점은 지금 내가 공장 확인했다 단, 싱글 톤 심하게 행해졌 다 잘 할 수 있었던 무엇을 알고 디자인 패턴을 알고 있다는 것입니다 수있는 전략 패턴이 훨씬 더 실제로 경우했을왔다 했던 전략 패턴.

— 이진 걱정

3

... 디자인 패턴에 대해 배우고 올바르게 사용하는 방법을 배우면 많은 시간을 절약 할 수 있습니다. 휠을 재발 명하려고 시도 할 가능성이 적고, 나쁜 디자인으로 나아가는 길을 이끌지 못하고 나쁜 솔루션을 구축하지 못하게됩니다. 그것을 빨아 들이고 패턴을 배우고 그들이 당신을 위해 일할 때 사용하고, 그렇지 않을 때 사용하지 마십시오.

— 이진 걱정

1

그리고 이것은 패턴에 대한 나의 견해를 정확하게 요약합니다. 그들은 당신이하고있는 일을 다른 사람들과 의사 소통하는 훌륭한 도구입니다. 모든 문제가 다르기 때문에 정확하게 빌드하지는 않습니다 . 그러나 그것들은 요점, 방향, 그리고 따라야 할 대략적인 지침이며, 당신이하고있는 일을 다른 사람들에게 쉽게 설명 할 수있게합니다.

— Matt D

물리적 구조와의 비교 +1 "트러스"가 지붕이 무너지지 않기를 기대하기보다는 지붕의 하중을 지탱하기에 좋은 구조라는 것을 이미 알고 있다면 집을 짓는 데 도움이 될 것입니다.

— kdgregory

39

과거를 기억할 수없는 사람들은 그것을 반복하도록 정죄받습니다.

디자인에서 발생 된 문제 이외의 특정 문제는 발생하지 않습니다. 그리고 시간이 지나면 인식하지 않고 패턴을 사용하게되며, 스스로 패턴을 알아내는 데 시간을 보냈습니다. 패턴을 미리 알고 있으면 디자인을 쉽게 파악할 수 있고 여러 개인에 의해 입증 된 주요 이점이 있습니다.

오늘날 개발되고있는 모든 것은 주로 이전 지식에 기반을두고 있으므로 무시하는 것은 의미가 없습니다. 수백 년 전에 성당을 지은 사람들이 직면 한 문제를 모르고 오늘 마천루를 건축한다고 상상해보십시오.

— devnull
소스

10

"모든 인용문은 똑같이 반대 인용문이 있습니다." "우리가 진정으로 미래를받을 자격이 되려면 과거를 찢어 버려야합니다." (하나는 히틀러 였으므로 무시하는 것이 가장 좋습니다 ....)

— Russell

20

소프트웨어 디자인 패턴을 사용하지 않으면 어떤 문제가 발생할 수 있습니까?

소프트웨어를 작성할 수없는 문제가 있습니다.

변수는 디자인 패턴입니다.

방법은 디자인 패턴입니다.

더하기, 빼기 등의 연산자는 디자인 패턴입니다.

문장은 디자인 패턴입니다.

값은 디자인 패턴입니다.

참조는 디자인 패턴입니다.

식은 디자인 패턴입니다.

클래스는 디자인 패턴입니다.

...

항상 프로그래밍에서하는 모든 일은 디자인 패턴 입니다. 대부분의 경우 패턴은 생각에 너무 깊이 뿌리 내려서 "디자인 패턴"으로 생각하지 않습니다. "단일 패턴"등과 같이 배워야하는 것은 단순히 사용중인 언어로 구워지지 않은 패턴입니다.

표준 객체 지향 기술을 사용하여 디자인에 접근하는 문제에 대해 알려줄 수 있습니까?

아니요.이 질문의 의미가 무엇인지 잘 모르겠습니다. 디자인 패턴 은 "표준 객체 지향 기술" 입니다. 이것이 디자인 패턴을 만드는 이유 입니다. 디자인 패턴은 (는 아니지만 특히, 특정 문제를 해결하기위한 표준 기술이다 반드시 객체 지향 언어).

— 에릭 리퍼 트
소스

1

The things that you have to learn like "the singleton pattern" and so on are simply patterns that haven't (yet) been baked into whatever language you're using.

-그것은 (거의) 디자인 패턴의 정의입니다-언어 자체의 한계를 극복하기 위해 사용되는 유연하고 쉽게 재사용 가능한 코드 구조로, 다른 사람들과 쉽게 대화 할 수 있습니다. 언어의 일부가되면 더 이상 디자인 패턴이 아닙니다.

— 이즈 카타

1

@Izkata : C #에서는 이벤트 형태로 언어에 관찰자 패턴이 내장되어 있기 때문에 C #에서는 관찰자 패턴을 사용할 수 없습니다. 바보입니다. 패턴과 관련된 언어 별 비트는 언어에서 패턴을 구현하는 표준 방법입니다. 물론 디자인 패턴을 직접 지원하는 언어로 사용할 수 있습니다. 그것이 바로 그들을 직접 지원하는 요점입니다!

— Eric Lippert

나는 불가능하다고 말한 적이 없다. 나는 불필요한 것을 암시하려고했다 . 예를 들어 Java 에는 이벤트가 없으므로 디자인 패턴을 사용하여 시뮬레이션합니다.

— 이즈 카타

@Izkata : 그때 혼란 스러워요. 일단 패턴이 언어의 일부가되면 더 이상 패턴이 아니라고 말했습니다. 그래서 "관찰자 패턴"패턴입니다 자바 하지만 되지는 C #에서 패턴?

— Eric Lippert

1

다시 말해, 디자인 패턴은 영어로 설명 할 수있는 것보다 프로그래머가하는 모든 것입니다. 나는 그 정의에 전적으로 동의한다고 확신하지는 않지만, 그것은 그것이 당신이 말하는 것을 정확하게 반영하고 적어도 패턴으로 간주되는 주관적인 판단이 없다는 이점을 가지고 있다고 생각합니다. 프로그래머가하는 일에 대한 분석의 속성이며, 물론 프로그래머가 분석 할 수없는 방식으로 행동하는 것은 불가능합니다. :-)

— Steve Jessop

4

문자에 사용하는 것보다 디자인 패턴의 요점을 이해하는 것이 중요합니다. 적어도 익숙한 언어 패러다임에서 일부 패턴은 바보입니다. 디자인 패턴을 맹목적으로 사용하고 실제로 이해하지 못하는 프로그래머 인 IMO는 사물을 통해 생각하고 싶은 프로그래머보다 더 나쁜 프로그래머입니다. 그러나 아이디어에 익숙해지고 자신이 가치가 있는지 여부를 스스로 결정하는 사람은 어느 것보다 훨씬 강력한 프로그래머가 될 것입니다.

즉, 플라이급의 요점이 무엇인지! @ # $ ing 생각이 없으며 그것을 인정하는 것이 부끄러워하지 않습니다. (많은 도움이 된 다른 위키 백과 항목에 대한 주석 참조)

디자인 패턴에 대한 wikipedia의 항목을 추천합니다. 매우 간결하고 명확하게 작성되었습니다. 왜 주어진 디자인 패턴으로 귀찮게 할 수 있는지에 대한 아이디어를 얻는 데 매우 도움이됩니다. 나는 개인적으로 가장 간단한 것을 가장 유용하게 생각하며 내 요구에 맞게 패턴의 주어진 구현을 수정하는 것에 대해 두 번 생각하지 않을 것입니다.

그들은 청사진이 아니라 아이디어입니다. 일부 언어에서는 전혀 좋은 아이디어가 아닙니다. 다른 언어에서는 언어의 설계 약점을 극복하고 복잡성을 줄임으로써 더 잘 보상 할 수있는 kludges로 간주됩니다. 그럼에도 불구하고, 자신이 선호하는 솔루션을 결정하기 전에이를 검토하고 그들이 극복해야 할 과제를 이해하려고 노력하는 것이 아프지 않습니다.

어떤 종류의 문제에 직면하게됩니까? 이미 모든 것을 알아 낸 프로그래밍 천재가 아니면 기회를 놓치고 필요한 것보다 더 많은 시간을 할애 할 수 있습니다. 대중적인 프로그래밍 아이디어에 대해 비판적인 시각을 유지하는 것이 중요하지만, 사람들이 자신이 선호하는 솔루션 / 접근 방식에 대해보다 명확하게 설명하기 때문에 사람들이 해결하려는 생각을 이해하는 것은 결코 아프지 않습니다.

— 에릭 레펜
소스

2

플라이 웨이트 (플라이휠 아님). wikipedia 기사 의 첫 번째 단락 (그리고 첫 번째 단락 만)을 읽고 Integer.valueOf (int) 를보고 이것이 공통 값에 대해 새 정수를 작성하지 않는 횟수를 고려하십시오.

2

@MichaelT 그리고 젠장. 그것은 내가 본 것보다 훨씬 더 나아졌습니다. 감사.

— Erik Reppen

대부분의 디자인 패턴 지침에서 볼 수있는 문제는 큰 프로젝트 뷰를 제공한다는 것입니다 (GoF 책은 작은 작업이 아니라 워드 프로세서 작성에 관한 것입니다). 그러나 때때로 그들은 훨씬 더 작은 (거의 '사소한') 것들에 적용 할 수 있습니다. 7 줄의 코드는 모든 사람이 지속적으로 사용하는 것으로 플라이급을 깨끗하게 설명 할 수 있습니다. 큰 프로젝트 나 고안된 예보다 이해하기 훨씬 쉽습니다.

1

@MichaelT 저에게 그것은 프로토 타입 상속과 클로저가 일반적으로 그 문제를 해결하는 데 사용되는 기본 언어 인 JavaScript에서 아이디어가 즉시 사용되지 않더라도 일반적으로 코드를 작성하는 데 도움이되는 방법에 대한 좋은 예입니다. 문제. 그 아하 순간은 여전히 관련 아이디어를 주었다.

— Erik Reppen

2

직면하게 될 주요 문제 는 휠을 재발 명 한다는 것입니다 . 패턴은 자주 예측 가능한 방식으로 나타나기 때문에 패턴이라고합니다.

— pgpb.padilla
소스

0

디자인 패턴을 따르더라도 디자인이 잘못 될 수 있습니다. 디자인 패턴은 자연스럽고 디자인에 약간의 맛을 사용하게됩니다. 패턴을 사용하지 않으려면 정말 열심히 노력해야합니다. 디자인 패턴을 비난 할 이유가 없습니다. 더 중요한 것은 필요에 맞는 패턴을 선택하는 것입니다

— 비수
소스

-1

디자인 패턴을 인식하지 않고 항상 사용하고 있습니다. 널리 사용되는 언어로 된 많은 표준 라이브러리는 디자인 패턴을 염두에두고 설계되었습니다. 예는 데코레이터 디자인 패턴을FileReader 사용하여 설계된 Java 라이브러리 입니다 . 이제 자신의 코드 에 대해 이야기 할 때 디자인 패턴을 사용하지 않아도됩니다 (대부분의 경우). 디자인 패턴은 "일반적으로 발생하는 문제에 대한 재사용 가능한 솔루션"입니다 . 즉, 유지 관리가 더 깔끔한 코드를 작성하는 데 도움이되므로 스파게티 코드로 끝나지 않으려는 정도에 달려 있습니다.

— 정통
소스