패턴과 원리의 차이점

20

객체 지향 디자인 패턴과 원칙의 차이점은 무엇입니까? 그것들이 다른가? 내가 이해하는 한 두 가지 공통 목표 (예 : 유연성)를 달성하려고합니다. 패턴이 원칙이고 그 반대도 마찬가지라고 말할 수 있습니까?

설계 원리 = SOLID (즉, 의존성 역전 원리)

디자인 패턴 = Gof (예 : 추상 팩토리 패턴)

— 찬디 고롬
소스

24

아니요, 동일하지 않습니다.

패턴은 객체 지향 프로그래밍 문제에 대한 일반적인 솔루션 입니다. (저는 기능적 또는 선언적 프로그래밍에 대한 유사한 책을 알고 있지 않습니다.) 1995 년 Gang of Four의 유명한 "Design Patterns"책에서 아이디어가 구체화되었습니다.

Andre가 지적한 것처럼 패턴은 모든 패러다임에서 일반적입니다. 나는 이전의 진술을 되풀이 할 것이다. 나는 기능적 또는 선언적 프로그래밍에 대한 비슷한 책을 알고 있지 않지만, Andre는 아래에 제공된 링크로 무지를 수정했다. 감사합니다, 안드레

원칙은 특정 언어 나 패러다임에 관한 것이 아니라 일반적입니다. "자신을 반복하지 마십시오"-DRY 원칙-모든 프로그래밍에 적용됩니다.

— 더 피모
소스

4

패턴은 모든 패러다임에 존재합니다. 제레미 기븐스는 책이라고 쓰고 프로그래밍 기능에 패턴 (그리고 그것에 대해 블로깅 여기 ). 패턴은 비슷한 문제를 해결하는 반복 디자인과 같은 이름입니다. 그들은 당신이 항상 그들을 인식하지 못할 수도 있지만, 어디에나 있습니다.

— André Paramés 2016 년

@ AndréParamés 잠깐 동안 나는 Jeremy Gibbons가 디자인 패턴이 아니라 언어 관용구 에 대해 이야기하고 있다고 믿게되었습니다 .

— 이즈 카타

@Izkata Non-OOP 디자인 패턴?

— Roc Martí

19

이러한 개념은 동일하지 않습니다.

* 디자인 원칙 : * 소프트웨어 디자인 원칙은 잘못된 디자인을 피하는 데 도움이되는 일련의 지침을 나타냅니다. 같은 : 오픈 닫기 원칙

* 디자인 패턴 : * 디자인 패턴은 소프트웨어 디자인의 주어진 맥락에서 일반적으로 발생하는 문제에 대한 일반적인 재사용 가능한 솔루션입니다. 좋아요 : 싱글 톤

— 제니퍼 S
소스

7

패턴은 원칙, 구현은 패턴에 대한 것입니다.

원칙은 "간접"이며, "공장"패턴에 의해 달성 될 수 있으며, 결국 팩토리 메소드를 가진 클래스로 구현됩니다.

— 케이..
소스

3

글쎄, 원칙은 규칙이지만 패턴은 구체적인 예입니다.

— 아마드
소스

1

몇 가지 예를 들어 줄 수 있습니까?

공장 또는 책임 체인 또는 Flyweight를 요구하는 원칙을 알려주십시오.

— duffymo 2016 년

2

@duffymo Well Factory는 예를 들어 Dependency Inversion Principle (주사 아님)을 따릅니다. 클라이언트와 인스턴스는 모두 추상화-인터페이스에 의존합니다. 책임의 사슬은 통제의 느슨한 결합과 분리의 원리에 기초합니다. Flyweight 나는 단지 성능 향상을 가지고 있다고 생각합니다.

— m3th0dman 2011

3

패턴은 원칙보다 더 높은 수준의 것입니다. 패턴은 특정 문제를 해결합니다. 원칙은 상황에 관계없이 어느 곳에서나 적용될 수 있습니다. 원칙 (SRP, DRY 등)을 기반으로 한 실제 패턴

EG 전략 패턴을 살펴 보겠습니다. 알고리즘 제품군을 정의하고 각 알고리즘을 캡슐화하며 상호 교환 가능하게 만듭니다. 따라서 여기에는 고급 알고리즘 개념이 있습니다. 상태 패턴을 사용하면 높은 수준의 상태 개념이 있습니다. 원칙적으로는 높은 수준의 개념이 없습니다. 원칙은 후두둑이 목표를 달성하기 위해 사용하는 빌딩 블록입니다. 전략 패턴을 구현할 때 SOLID를 사용합니다.

SRP-알고리즘을 담당하는 코드를 정의하고 다른 코드에서 추출합니다.
OCP-모든 다른 알고리즘을 나타내는 추상화를 정의하고 사용합니다.
LSP-클라이언트 코드에서 구체적인 알고리즘 클래스를 사용하지 않고 추상화 만

— 게으른
소스

5

실제로 패턴은 원칙보다 낮은 수준입니다. 즉, 패턴은이 맥락에서 원칙보다 실제 구현에 더 가깝습니다. 다시 말해서, 원리는 일반적인 설계 지침을 의미하는 원리를 가진 패턴과 특정 종류의 문제에 적합한 솔루션을 나타내는 패턴보다 원리가 더 추상적입니다.

@Jarkko 내 예를 참조하십시오. 수준에 대해 이야기 할 때 패턴이 원칙이 아니라 원칙에 기반을 둔다는 것을 의미했습니다. 벽돌은 건물보다 더 높은 수준의 것이 아닙니다.

4

나는 당신이 그 의미를 알 수 있고 그 문제에 대한 당신의 생각을 이해할 수 있습니다. 그러나 이는 소프트웨어의 맥락에서 "고수준"과 "저수준"이라는 개념의 일반적인 의미와 상반됩니다. (어떤 이유로 당신을 @ -tag 할 수 없습니다.)

1

"패턴은 원칙보다 더 높은 수준의 것"입니다. 나는 ==> 다른 것을 구걸한다. 패턴은 실현에 가깝다 (즉, 낮은 수준), 원리는 높은 수준의 규칙이다.

— Raúl

2

아키텍처에 대해 원래 문서화 된 패턴 건축에서는 방의 문 배치에서부터 마을의 레이아웃에 이르기까지 다양한 분야에 적용됩니다.

Gang of Four는이 아이디어를 객체 지향 프로그래밍에 적용했습니다. 문제를 해결하는 데 사용할 수있는 패턴이 둘 이상있을 수 있지만 각 패턴에는 특정 구현이 있습니다. 패턴은 다른 프로그래밍 방식에 존재하지만 적용 가능한 책을 알지 못합니다. 다른 사람들이 언급했듯이 패턴은 특정 구현을 다룹니다. 적용되지 않을 때 패턴을 사용하는 것은 종종 안티 패턴으로 간주됩니다.

표준 구현 방법이있을 수 있지만 원칙은 구현을 다루지 않습니다. 원칙은 특정 문제보다는 일반적인 문제를 다루는 것에 관한 것입니다. Inversion of Control의 경우 적어도 세 가지 구현 방법을 알고 있습니다. DRY (자체를 반복하지 마십시오)의 경우 여러 가지를 사용하지만 단일 특정 구현 방법을 모르겠습니다.

치다

프로그램을 개발하는 유일한 방법으로 Abstract Factory Pattern과 같은 Pattern을 사용하도록 요청되었습니다. 이것이 적절할까요? 아니요, 패턴 일 가능성이 높습니다.
모든 구성 요소에 DRY를 적용하도록 요청 되었습니까? 이것이 적절할까요? 그렇다면 원칙이 될 가능성이 더 큽니다.

— BillThor
소스

1

OO 설계 원칙 —

OO 원칙은 OOP 개념을 보장하는 일련의 지침입니다. OOP 개념을 기반으로 더 나은 방식, 더 나은 디자인을 디자인하는 방법을 정의합니다. 기본 OO 설계 원칙은 SOLID입니다.

디자인 패턴은 디자인 문제에 대한 일반적인 솔루션을 제공합니다. 정오 객체 지향 단어에도 "디자인 패턴"을 적용 할 수 있습니다. 따라서 OODP (OO) 디자인 패턴 (OODP)은 객체 지향 디자인 기반 OO 원칙에 대한 일반적인 솔루션을 제공하는 패턴입니다. 발명되지 않은 디자인 패턴이 발견됩니다. OODP를 정의하는 방법에는 여러 가지가 있으며 가장 유명한 방법은 BSC (Behavioral Structural Creational)입니다.

다음은 자세한 설명을위한 링크입니다. http://techythought.wordpress.com/2013/01/21/design-principle-vs-ds-design-pattern-describing-oop-elements/

— 탠지
소스