여러 버전이있는 응용 프로그램을 만드는 디자인/아키텍처 패턴이 있는지 궁금 할 것입니다 (예 : Windows에 Home, Standard 또는 Ultimate 버전이있는 방법).여러 버전의 응용 프로그램을위한 디자인 패턴
주요 아이디어는 사용자에게 기본 버전, 고급 버전, 전체 버전에 따라 다양한 기능을 제공하는 응용 프로그램을 만들고 싶습니다. 누군가 플러그인을 사용하라고 제안했는데 ... 좋은 제안입니까?
감사합니다.
다양한 옵션이 있습니다.
개념적으로 가장 간단한 것은 가능한 한 다시 사용하여 3 가지 응용 프로그램을 작성하는 것입니다. 따라서 공유 기능을 제공하는 "엔진"과 엔진에서 실행되는 3 개의 개별 응용 프로그램 (기본, 고급, 전체)을 가질 수 있습니다. 이것은 MS 운영 체제의 특징 인 것입니다. 엔진은 기본 운영 체제이고 다른 버전에는 엔진 위에 다양한 응용 프로그램이 포함되어 있습니다.
이 경로의 이점은 개념적으로 유효한 제품을 만들 수 있다는 것입니다. 버전간에 많은 의존 관계가 없으며 "전체"버전이 "기본"버전의 기능을 포함하지 않기로 결정한 경우 말이 안되기 때문에, 그 의존성을 깨뜨리는 것에 대해 걱정할 필요가 없습니다.
두 번째 모델은 단일 응용 프로그램을 빌드하고 빌드 또는 런타임에 구성을 통해 동작을 제어합니다. 예를 들어 "ifdef"는 단일 C 코드 파일이 다른 운영 체제를 대상으로 할 수있게합니다. 동일한 SQL 데이터베이스 엔진의 여러 가지 버전으로 지원되는 프로세서의 수는 런타임 구성에 의해 제어 될 수 있습니다.
이렇게하면 관리 할 단일 코드베이스가 있지만 편집간에 매우 긴밀한 결합이 발생하고 관리하기 쉽지 않게된다는 장점이 있습니다.
많은 응용 프로그램이 "플러그인"모델을 사용합니다. 이것은 첫 번째 옵션의 변형입니다. 먼저 프레임 워크 응용 프로그램을 작성해야하며 각 버전의 기능은 프레임 워크에서 수행 할 수있는 기능으로 제한됩니다. 많은 게임웨어가 이런 방법으로 설계되었으며, 버전 간의 차이는 기본적으로 어떤 플러그인이 게임과 함께 제공되는지에 달려 있습니다.
이것은 구조적으로 매우 깨끗하지만 프로젝트에 실질적인 위험을 초래합니다. 가장 현명한 개발자는 모두 프레임 워크에서 작업하기를 원하지만 실제 제품을 다루는 사람은 아무도 없습니다. 프레임 워크 개발자가 실제 요구 사항이 무엇인지 잘못 판단하면 잘못된 제품을 지원하는 훌륭한 프레임 워크가됩니다. 또한 프레임 워크는 로깅이나 플러그인 구성과 같은 컴퓨터 과학 문제에 중점을두고 실제 비즈니스 질문에는 그다지 집중하지 않는 경향이 있습니다. 나는 이것을 처음으로 보았다. 그리고 그것은 다소 비극적이었다.
시간과 예산을 제한하지 않는 한, 옵션 1부터 시작하여 첫 번째 출시가 결정되면 옵션 3으로 발전합니다.
이 상황에서 패턴이 도움이되지 않을 것이라고 생각합니다.
이러한 모든 버전 (기본, 고급, 전체)은 다양한 모듈 집합에서 다릅니다. 프로그램에서 좋은 모듈성을 지원하는 경우 모듈 집합을 설정할 수있는 각 버전에 해당하는 빌드 스크립트 만 분리 할 수 있습니다.
플러그인을 사용하면됩니다. – Glenner003