디자인 패턴과 건축 패턴의 차이점은 무엇입니까?

인터넷에서 디자인 패턴 에 대해 읽을 때 세 가지 범주가 있음을 알 수 있습니다.

• 창조
• 구조적
• 행동

그러나 소프트웨어 아키텍처를 만들 때 MVP, MVC 또는 MVVM에 대해 생각합니다.

예를 들어, 창조 패턴 중에서 싱글 톤 패턴을 찾았 지만 MPV에서도 싱글 톤을 사용했습니다.

그래서 제 질문은 : 디자인 패턴이 제품의 모든 구조에 해당합니까?

• 그렇다면 싱글 톤이 디자인 패턴이 될 수있는 방법은 무엇입니까? 내 응용 프로그램의 어디에서나 사용할 수 있기 때문입니다. 기본적으로 메모리에서 한 번에 하나의 인스턴스 만 생성하도록 제한되지만이 개념이 소프트웨어 설계 방식을 정의하지 않습니까?

• 그렇지 않다면 세 가지 패턴 범주에서 MVP, MVC 및 MVVM은 어디에 있습니까? 그리고 소프트웨어의 디자인과 아키텍처의 차이점은 무엇입니까?

자세한 설명이 필요하지만 내가 아는 한 차이점을 스케치하려고 노력할 것입니다.

패턴 은 프로그램에서 찾을 수있는 증류 된 공통성입니다. 이를 통해 크고 복잡한 구조를 해체하고 간단한 부품을 사용하여 구축 할 수 있습니다. 문제 클래스에 대한 일반적인 솔루션을 제공합니다.

크고 복잡한 소프트웨어는 여러 수준에서 일련의 해체를 거칩니다. 큰 수준에서 아키텍처 패턴은 도구입니다. 더 작은 수준에서 디자인 패턴은 도구이고 구현 수준에서는 프로그래밍 패러다임이 도구입니다.

패턴은 매우 다른 수준에서 발생할 수 있습니다. 프랙탈을 참조하십시오 . 빠른 정렬, 병합 정렬은 모두 요소 그룹을 순서대로 구성하기위한 알고리즘 패턴입니다.

가장 단순한보기 :

• 프로그래밍 패러다임 -프로그래밍 언어에만 해당
• 디자인 패턴 -소프트웨어 구성에서 반복되는 문제 해결
• 아키텍처 패턴 -소프트웨어 시스템의 기본 구조 조직

관용구 는 낮은 수준의 세부 정보를 채우는 패러다임 별 및 언어 별 프로그래밍 기술입니다.

디자인 패턴 은 일반적으로 코드 수준 공통성과 관련됩니다. 더 작은 하위 시스템을 개선하고 구축하기위한 다양한 계획을 제공합니다. 일반적으로 프로그래밍 언어의 영향을받습니다. 일부 패턴은 언어 패러다임 으로 인해 희미 해집니다 . 디자인 패턴은 엔터티의 구조와 동작 및 관계의 일부를 구체화하는 중간 규모의 전술입니다.

하지만 건축 패턴 디자인 패턴보다 높은 수준에서 공통점으로 볼 수 있습니다. 아키텍처 패턴은 대규모 구성 요소, 시스템의 전역 속성 및 메커니즘과 관련된 고급 전략입니다.

패턴은 어떻게 얻습니까? 을 통하여:

1. 재사용,
2. 분류
3. 마지막으로 공통성을 추출하기위한 추상화입니다.

위에 놓인 생각을 따랐다면. Singleton은 "디자인 패턴"이고 MVC는 문제 분리를 처리하는 "아키텍처"패턴 중 하나입니다.

다음을 읽어보십시오.

1. http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science)
2. http://en.wikipedia.org/wiki/Design_pattern
3. http://en.wikipedia.org/wiki/Anti-pattern

디자인 패턴은 여러 번 입증 된 방식으로 기술적 문제를 해결하기위한 잘 알려진 패턴입니다. 디자인 패턴은 재사용 가능한 객체 지향 소프트웨어를 만드는 일반적인 디자인 구조 및 관행입니다. 디자인 패턴의 예로는 Factory Pattern, Singleton, Facade, State 등이 있습니다. 디자인 패턴은 애플리케이션 전체에서 작은 문제를 해결하는 데 사용할 수 있으며 전체 아키텍처보다 주입, 변경, 추가가 훨씬 쉽습니다.

아키텍처 패턴은 소프트웨어 애플리케이션 아키텍처 문제를 해결하기위한 잘 알려진 패턴입니다. 소프트웨어 애플리케이션 아키텍처는 모든 기술 및 운영 요구 사항을 충족하는 구조화 된 솔루션을 정의하는 프로세스입니다. 애플리케이션의 아키텍처는 코드의 전체 '조직'입니다. 다른 아키텍처의 예로는 MVC, MVVM, MVP, n- 레이어 (예 : UI-BLL-DAL) 등이 있습니다. 아키텍처는 일반적으로 미리 결정해야하며 애플리케이션이 빌드 된 후에는 변경하기 어려운 경우가 많습니다.

아키텍처 요소는 일반적으로 상자로 표시되는 클래스 또는 모듈 모음을 선호합니다. 아키텍처에 대한 다이어그램은 아래를 내려다 보는 가장 높은 수준을 나타내는 반면 클래스 다이어그램은 가장 원자 수준입니다. 아키텍처 패턴의 목적은 시스템의 주요 부분이 어떻게 결합되는지, 메시지와 데이터가 시스템을 통과하는 방식 및 기타 구조적 문제를 이해하는 것입니다. 아키텍처 패턴은 일반적으로 연속적으로 더 작은 모듈로 구성된 다양한 구성 요소 유형을 사용합니다. 각 구성 요소는 아키텍처 내에서 책임이 있습니다. 디자인 패턴은 응용 프로그램의 작은 입자를위한 저수준 또는 클래스 수준 디자인 패턴입니다.

자세한 정보 : https://www.oreilly.com/ideas/contrasting-architecture-patterns-with-design-patterns

음, 주요 부분은 언어의 문제입니다. 내 경험에 따르면 소프트웨어에 관한 한 디자인과 건축의 경계선은 주로 마케팅 시즌의 영향을받는 수위로 인해 폭이 넓은 넓은 강입니다. 일반적으로 "디자인"이라는 용어는 최종 사용자가 인식하는 소프트웨어 제품 동작의 강력한 측면과 함께 사용되는 반면 "아키텍처"는 소프트웨어의 기술적 구조, 즉 구성 요소, 라이브러리, 프로토콜 및이를 충족하는 데 필요한 모든 것을 나타냅니다. 디자인. "디자인 패턴"은 두 가지 역할을합니다. 첫째, 제품이 아닌 표준 문제의 범주를 해결하기위한 모범 사례로 간주됩니다. 두 번째는 개발자가 의사 소통을 할 수 있도록 도와줍니다. 싱글 톤의 예를 들으며 매번 설명하는 대신 단어를 사용하여 메커니즘이 무엇인지 알 수 있습니다. 제어 된 방식으로 설정되고 보장되는 지정된 데이터 공간 (변수 또는 기타)을 사용하여 단일 인스턴스를 만들었습니다. 우리가 클래스의 생성자를 보호했기 때문에 유일한 것입니다. 그래서 IMHO 귀하의 질문에 대한 짧은 대답은 : 그것은 누가 말하는지에 달려 있습니다. 그게 말이 되나?

디자인 패턴 은 범위가 아키텍처 패턴 과 다르며, 더 지역화되고, 코드베이스에 덜 영향을 미치며, 코드베이스의 특정 섹션에 영향을줍니다. 예를 들면 다음과 같습니다.

How to instantiate an object when we only know what type needs to be instantiated at run time (maybe a Factory Class?)
How to make an object behave differently according to its state (maybe a state machine, or a Strategy Pattern?)

아키텍처 패턴은 코드 기반에 광범위한 영향을 미치며, 대부분 수평 (즉, 레이어 내부에서 코드를 구성하는 방법) 또는 수직 (즉, 요청이 외부 레이어에서 내부 레이어로 처리되는 방법)에 전체 애플리케이션에 영향을 미칩니다. 뒤). 아키텍처 패턴의 예 : Model-View-Controller, Model-View-ViewModel