비 OOP 디자인 패턴? [닫은]

70

객체 지향 코드에 사용되는 "디자인 패턴"이라는 용어 만 들었고 GoF 패턴에는 OOP 디자인 패턴 만 포함되어 있지만 디자인 패턴은 일반적으로 발생하는 프로그래밍 문제에 대한 훌륭한 솔루션입니다. 거기에는 OOP로 제한되어야한다는 말이 없습니다.

객체 지향 프로그래밍 영역 밖에서 디자인 패턴의 몇 가지 예를보고 싶습니다 . 있니? 그러한 것조차 존재 하는가 (GoF 책과 같은 책이 반드시 쓰여져서는 안되며, 그냥 사용 되어야만한다. 충분하다)?

그것들은 일부 프로그래밍 언어에 특정적일 수 있지만, 객체 지향적 인 것 이외의 다른 패러다임 중에서 일반적인 (패러다임 수준) 패턴이 선호됩니다.

design-patterns 
— 안토
소스
8
대중적인 디자인 패턴 북이 가장 큰 장애는 패턴이 객체 지향 언어에만 적용된다고 생각하는 수많은 사람들을 만드는 것이 었습니다. 창조 패턴은 논란의 여지가 있지만, 거의 대부분은 다른 객체 지향 언어로 구현 될 수 있고 구현되지 않습니다. 나는이 부작용이 저자의 의도가 아니라고 생각한다. 부작용은 그다지 크지 않다.
— Pemdas
14
글쎄, 객체는 비 OO 언어에서 디자인 패턴입니다 :)
— back2dos
1
더 나쁜 것은, 패턴 책은 특정 패턴을 적용하여 모든 문제를 해결해야한다고 믿는 전체 계층의 사람들을 만들었다는 것입니다.
— jwenting

답변:

25

Linux Kernel Design Patterns 시리즈를 살펴보십시오. 이 기사는 비 객체 지향 언어 (C)와 관련이 있으며 잘 작성되었다고 생각합니다.

— 사키 스크
소스
그들은 객체 지향 접근법을 사용하고 있습니다.
— Kais
12

실제로 그것은 역설이다-가장 인기있는 비 -OO 패턴 중 하나는 "클래스"이다.

OO는 OO가 아닌 언어로 개발 되었기 때문에 개발자는이를 시뮬레이션해야했으며 (지금도 수행하고 있음) 패턴이 탄생했습니다. LISP와 C가 이에 대한 예입니다.

그러나 내 충고를 받아들이십시오 : 일반적인 실수를하지 마십시오-패턴이 멋지 기 때문에 패턴을 사용하지 마십시오. 패턴 사용 (적어도 OO 패턴)을 정당화 해야하는 심각한 이유가 필요합니다.

예를 들어 명령 패턴을 사용하십시오-비록 훌륭하고 수신자와 발신자를 분리하지만 실제로 필요하지 않는 한 사용해서는 안됩니다-연산을 동사를 사용하여 표현해야하기 때문에 메소드를 의미합니다. 그리고 모든 곳에서 명령을 사용하면 완전히 분산 된 여러 OO- 람다로 끝납니다-> 많은 전략에 대해서도 마찬가지입니다.

— 카밀 톰식
소스
11

"디자인 패턴"은 실제로 "해결 방법"의 완곡 어입니다. 디자인 패턴은 OO 언어의 단점과 결함을 해결하기 위해 고안되었습니다 . 예를 들어 반복자 패턴을 사용하면 결국 Java에 콜렉션이 도입됩니다. Groovy는 언어 기능으로 변환하여 더 많은 패턴을 제거했습니다. Groovy의 기존 클래스에 메소드를 추가 할 수 있으므로 데코레이터 패턴이 더 이상 필요하지 않습니다.

즉, 어디서나 디자인 패턴을 찾을 수 있습니다. 실제로 모든 "모범 사례"는 단순한 형태의 디자인 패턴으로 간주 될 수 있습니다.

— 아론 디 굴가
소스
9
동의했다! 에서 폴 그레이엄 : 패턴 ""예를 들어, OO의 세계에서 당신에 대한 좋은 거래를 듣고 "나는 내 프로그램의 패턴을 볼 때 [...], 나는 그것이 문제의 징조 고려 프로그램의 모양을 반영해야한다.. 코드의 다른 규칙은 적어도 충분히 강력하지 않은 추상화를 사용하고 있다는 것입니다. 종종 일부 매크로의 확장을 수동으로 생성한다는 표시입니다. 글을 써야합니다. "
— Andres F.
7
해결 방법 인 디자인 패턴에 동의하지 않습니다. 둘은 반대입니다. 해결 방법은 특정 장애물을 우회하기 위해 결합 된 단기 패치입니다. 디자인 패턴은 장기간 재사용 가능한 솔루션입니다. 데코레이터 패턴의 목적은 클래스를 수정하지 않고 기능적으로 '없이'추가하는 것입니다. 객체에 대해 알지 않고도 다른 데코레이터를 객체에 넣을 수 있습니다.
— Despertar
패턴이 "해결 방법"으로 간주되는 이유는 객체를 꾸미는 것이 언어의 특징이어야하기 때문입니다. 대신,이를 구현하기 위해 많은 수의 코드 줄을 작성해야합니다. 예를 들어, 반복자 패턴 은 많은 현대 언어의 일부가되었습니다. 구형 OO 언어의 경우 시뮬레이션을 위해 몇 개의 농구대를 뛰어 넘어야합니다.
— Aaron Digulla
@AaronDigulla 왜 데코레이터와 같은 패턴이 그렇게 무거운 구현이라고 생각하는지 모르겠습니다. 몇 줄의 코드에 대해 이야기하고 있습니다. 클래스는 다른 클래스를 포함하고 추가 된 기능으로 요청을 클래스에 전달합니다. 그것은 장식 된 객체를 호출하는 것과 객체 자체를 호출하는 것과 같은 방식으로 상속과 구성을 사용합니다. 나는이 투명성을 강점으로 생각합니다. 런타임에 데코레이터를 교체 할 수 있습니다. groovy는 클래스에 메소드를 추가 할 수 있기 때문에 데코레이터가 필요하지 않다고 말할 때 요점을 놓친 것처럼 들립니다.
— Despertar
2
Iterator 패턴은 현대 언어의 새로운 언어 기능으로 대체되지 않았습니다. 공통 컬렉션에 대한 기본 구현과 함께 제공됩니다. 기본 구현이 있다고해서 패턴이 사용되고 있지 않다는 의미는 아닙니다. 자신 만의 컬렉션을 작성한다면 직접 구현해야합니다.
— Despertar
10

LtU는 Jeremy Gibbons 가 함수형 프로그래밍의 패턴에 관한 책을 쓰고 있다고 언급 했습니다 . 티저에 대한 기능 프로그래밍 블로그에서 Mr. Gibbon의 패턴을 확인하십시오 . 그는 가장 오래된 게시물부터 가장 오래된 게시물까지 읽는 것이 좋습니다.

고서 데이터 형식-일반 프로그램으로서의 그의 논문 디자인 패턴 (pdf)은 기능적으로 복합, 반복자, 방문자 및 작성기의 네 가지 패턴을 모델링합니다. 그는 종이 접기 프로그래밍 (접고 펼치기) 에서 재귀 방정식으로 프로그래밍 패턴을 설명합니다 .

— 코빈 3 월
소스
7

비 oo 디자인 패턴의 이름을 지정하는 대신 많은 디자인 패턴을 가진 책의 몇 가지 예를 제시하고자합니다 (일부 패턴은 여전히 ​​OO에 따라 다름).

도움이 되었기를 바랍니다

— KeesDijk
소스
이것 또한 내가 추천하는 것들과 Hohpe & Woolf의 엔터프라이즈 통합 패턴 입니다.
— TMN
Fowler의 패턴은 매우 우수합니다 :)
— David Conde
@David Conde :) 대부분은 순수 OO이며, 모두 OO 방식으로 작성되었지만 일부는 OO가 아닌 경우에도 적용됩니다. "웹 프리젠 테이션 패턴", "세션 상태 패턴", "배포 패턴 "
— KeesDijk
0

대기열, 연결된 목록, 트리, 그래프 등과 같은 Data Strucutres를 패턴으로 생각하고 싶습니다. 데이터를 저장하고 처리 할 특정 패턴을 정의합니다. 그들은 Gang of Four의 고급 패턴에 비해 원시적 인 것처럼 보일 수 있지만 nevverthethe 패턴입니다. 누군가가 스택을 LIFO 대신 FIFO로 구현하고 그 반대의 경우 대기열에 대해 다른 이름을 지정하면 어떻게 될까요?

— DPD
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.