확장 가능한 소프트웨어(플러그인 아키텍처)를 설계하는 방법은 무엇입니까?[닫은]
-
11-07-2019 - |
문제
확장 가능하도록 소프트웨어를 설계하는 방법에 대해 설명하는 리소스가 필요합니다.다른 사람들이 기능을 추가하는 추가 기능/플러그인을 작성할 수 있도록 합니다.
추천 메뉴가 무엇인가요?이 주제를 다룬 책이 있나요?
나는 짧고 요점이 분명한 것을 선호합니다.약간의 이론과 많은 구체적인 예.
특정 언어를 타겟으로 삼는 것이 아니라, 어떤 언어로든 구현할 수 있도록 핵심 아이디어를 이해할 수 있도록 하고 싶습니다.
그리고 같은 이유로, 나는 다른 사람이 만든 프레임워크를 사용하는 것을 선호하지 않습니다(프레임워크가 매우 높은 수준이 아닌 한, 즉숨기지 않는다 ~도 많이), 지금은 주제에 대해 교육하고 이를 구현하는 다양한 방법을 실험하고 싶습니다.또한 프레임워크는 일반적으로 해당 주제에 대한 사용자의 지식을 가정합니다.
업데이트
나는 OOP에 대해 묻거나 내 클래스가 상속되도록 허용하는 것이 아닙니다.저는 배포된 후 타사 추가 기능을 통해 확장될 수 있도록 시스템에 배포될 애플리케이션을 설계하는 것에 대해 이야기하고 있습니다.
예를 들어, Notepad++에는 플러그인 폴더에 .dll 파일을 배치할 수 있는 플러그인 아키텍처가 있으며 색상 선택, 조각 삽입 등 거기에 없던 기능을 애플리케이션에 추가합니다. (다양한 기능).
해결책
우리가 .net을 말하고 있다면 시도하십시오 vbscript를 사용하여 .NET 응용 프로그램을 스크립팅합니다 CodeProject에서. 많은 구체적인 예가 있습니다.
다음은 다양한 응용 프로그램 확장 기술을 구현하는 사이트입니다
다른 팁
오지 당신이 따르는 일을 할 수있는 기술 프레임 워크의 실용적인 예입니다.
그만큼 이론이 여기 있습니다.
그만큼 (무료!) 책이 있습니다.
확장 가능성과 플러그인을 작성하는 기능은 처리해야합니다. 서비스 수명주기
- 현장에서 서비스 / 플러그인 추가 / 제거
- 서비스 간의 종속성 관리
- 서비스 상태 관리 (선언, 설치, 시작, 중지, ...)
모듈의 주요 기능 중 하나는 배포 단위입니다. 응용 프로그램의 기능을 확장하기 위해 빌드하거나 다운로드하여 설치할 수있는 것입니다.
당신은 찾을 것입니다 여기에 좋은 소개, 중심 개념에 서비스 (귀하의 질문과 관련이 있으며 서비스 주변의 몇 가지 문제, 확장성에 대한 주요 구성 요소).
발췌:
많은 애플리케이션이 너무 많은 응용 프로그램을 구축 할 수 있다면 서비스가 중요한 이유는 무엇입니까? 서비스는 소프트웨어 구성 요소를 서로 분리하는 가장 잘 알려진 방법입니다.
서비스의 가장 중요한 측면 중 하나는 클래스 로딩 문제가 클래스 이름이 아닌 객체의 인스턴스와 함께 작동하기 때문에 클래스 로딩 문제를 크게 최소화한다는 것입니다. 소비자가 아닌 공급자가 생성 한 인스턴스. 복잡성의 감소는 매우 놀랍습니다
서비스는 구성을 최소화 할뿐만 아니라 공유 패키지의 수를 크게 줄입니다.
당신은 두 가지 상충되는 목표를 달성하려고 노력합니다.
- 소프트웨어의 구성요소는 노출되어야 합니다. 많이 자체적으로 재사용할 수 있도록
- 소프트웨어의 구성요소는 노출되어야 합니다. 아주 작은 자체적으로 재사용할 수 있도록
설명:코드 재사용을 장려하려면 기존 클래스를 확장하고 해당 메서드를 호출할 수 있어야 합니다.메서드가 "private"으로 선언되고 클래스가 "최종"(확장할 수 없음)인 경우에는 이것이 불가능합니다.따라서 이 목표를 달성하려면 모든 것이 공개되고 접근 가능해야 합니다.개인 데이터나 방법이 없습니다.
소프트웨어의 두 번째 버전을 출시하면 버전 1의 아이디어 중 상당수가 완전히 잘못되었음을 알게 됩니다.많은 인터페이스나 코드, 메소드 이름, 삭제 메소드를 변경하고 API를 중단해야 합니다.이렇게 하면 많은 사람들이 외면하게 될 것입니다.따라서 소프트웨어를 발전시킬 수 있으려면 구성 요소가 코드 재사용을 희생하면서 꼭 필요하지 않은 것을 노출해서는 안 됩니다.
예:SWT StyledText에서 커서(캐럿)의 위치를 관찰하고 싶었습니다.캐럿은 확장할 수 없습니다.그렇게 하면 코드에 "이 클래스가 org.eclipse.swt 패키지에 있습니까?"와 같은 검사가 포함되어 있고 많은 메소드가 비공개이고 최종적이며 기타 등등임을 알 수 있습니다.모든 것이 잠겨 있기 때문에 이 기능을 구현하기 위해 SWT의 약 28개 클래스를 프로젝트에 복사해야 했습니다.
SWT는 사용하기 좋은 프레임워크이고 확장하기에는 지옥입니다.
구현하다 단단한 응용 프로그램의 원칙.
1. 단일 책임 원칙 : 클래스는 단일 책임 만 있어야합니다 (즉, 소프트웨어 사양의 잠재적 변경 만 하나만 클래스의 사양에 영향을 줄 수 있어야합니다.
2. OPEN/CLISED 원리 : 소프트웨어 엔티티… 확장을 위해 열리지 만 수정을 위해 닫힙니다
3. Liskov 대체 원리 : 프로그램의 오브젝트는 해당 프로그램의 정확성을 변경하지 않고 하위 유형의 인스턴스로 교체 할 수 있어야합니다.
4. 인터페이스 분리 원리 : 많은 클라이언트 별 인터페이스가 하나의 일반적인 목적 인터페이스보다 낫습니다
5. 의존성 반전 원리 : 하나는 추상화에 의존해야합니다. 콘크리트에 의존하지 마십시오
stackoverflow 질문 :
물론 유명한 오픈 폐쇄 원칙이 있습니다. http://en.wikipedia.org/wiki/open/closed_principle
글쎄, 그것은 언어에 달려 있습니다.
- C/C ++에서는 런타임에 라이브러리를 열고 내보낸 기능을 호출 할 수있는 LoadLibrary 기능이 있다고 확신합니다. 이것은 일반적으로 C/C ++에서 수행되는 방식입니다.
- .NET에는 반사가 있습니다.이 반사는 LoadLibrary와 유사한 (그러나 더 광범위한) 제공됩니다. 또한 관리 된 확장 프레임 워크와 같은 반사를 기반으로 구축 된 전체 라이브러리 또는 이미 귀하를 위해 대부분의 무거운 리프팅을하는 Mono.addins가 있습니다.
- Java에는 반사가 있습니다. 그리고 Eclipse IIRC와 같은 물건에 사용되는 JPF (Java 플러그인 프레임 워크)가 있습니다.
사용하는 언어에 따라 튜토리얼/책을 추천 할 수 있습니다. 이것이 도움이 되었기를 바랍니다.
기사 플러그인 기반 응용 프로그램 작성 매우 간단한 예를 사용하여 아키텍처의 다양한 부분의 책임을 명확하게 설명합니다. 소스 코드가 제공됩니다 (vb.net). 기본 개념을 이해하는 데 매우 도움이되었습니다.
체크 아웃 "CAB" - Microsoft 's 구성 응용 프로그램 빌딩 블록 프레임 워크. 나는 그들이 "웹 버전"도 가지고 있다고 생각합니다 ...
방금 스마트 클라이언트 응용 프로그램을 개발하기 시작했습니다. 이것들은 내가 고려하는 두 가지 옵션입니다.
Microsoft를 사용합니다 System.addin 네임 스페이스. 매우 유망한 것처럼 보이지만 최종 솔루션에는 약간 복잡 할 수 있습니다.
또는 스마트 클라이언트 - 복합 UI 애플리케이션 블록 Microsoft에서
최근에 나는 Composite UI 애플리케이션 블록과 System.Addin 네임 스페이스를 모두 작성하여 내 자신을 빌드하는 것을 보았습니다. 운전실에서 소스 코드를 사용할 수 있으므로 확장하기 쉽습니다. 우리의 최종 솔루션은 택시의 가벼운 버전이 될 것이라고 생각합니다. Unity Application Block
플러그인 아키텍처는 확장 성과 유연성으로 인기가 높아지고 있습니다.
C ++의 경우 Apache HTTPD 서버는 실제로 플러그인 기반이지만 모듈 개념이 대신 사용됩니다. 대부분의 Apache 기능은 캐시, 재 작성,로드 밸런싱 및 스레딩 모델과 같은 모듈로 구현됩니다. 내가 본 매우 모듈 식 소프트웨어입니다.
Java의 경우 Eclipse는 확실히 플러그인 기반입니다. Eclipse의 핵심은 플러그인의 또 다른 개념 인 번들을 관리하는 OSGI 모듈 시스템입니다. 번들은 더 적은 노력으로 모듈을 구축 할 수있는 확장 지점을 제공 할 수 있습니다. OSGI에서 가장 복잡한 것은 동적 특성이며, 이는 런타임에 번들을 설치하거나 제거 할 수 있음을 의미합니다. 더 이상 세워진 증후군이 없습니다!
.NET과 함께 일하는 경우, 우리의 연구는 스크립팅과 구성의 두 가지 접근 방식을 산출했습니다.
스크립팅
스크립트를 사용하여 오케스트레이션하여 수업이 수행 할 수있는 기능을 확장합니다. 즉, 좋아하는 .NET 언어로 편집 된 것을 동적 언어로 노출시키는 것을 의미합니다.
우리가 탐색 할 가치가있는 몇 가지 옵션 :
- Ironpython
- 아이언 루비
- 자바 스크립트 : 진, 쥬라기 그리고 JavaScript .NET 좋은 출발점입니다.
- script.net -> 이것은 우리의 관심을 불러 일으킨 첫 번째 사람이었습니다.
구성
.NET 4 이상으로 프로젝트를 시작하면 MEF (Managed Extensibility Framework)를 잘 살펴 봐야합니다. 앱의 기능을 플러그인 방식으로 확장 할 수 있습니다.
MEF (Managed Extensibility Framework)는 대규모 응용 프로그램의 유연성, 유지 보수 및 테스트 가능성을 향상시키는 .NET의 구성 레이어입니다. MEF는 타사 플러그인 확장성에 사용될 수 있거나 느슨하게 결합 된 플러그인과 같은 아키텍처의 이점을 일반 애플리케이션에 가져올 수 있습니다.
관리 된 애드 인 프레임 워크 또한 좋은 읽기입니다.
의견을 남기기에 반복 포인트가 충분하지 않기 때문에 이것을 답으로 게시하고 있습니다. SharpDevelop은 c#/vb.net/boo에서 응용 프로그램을 개발하기위한 IDE입니다. 새로운 메뉴 항목부터 완전히 새로운 언어에 대한 개발 지원에 이르기까지 여러 가지 방법으로 확장 할 수있는 매우 인상적인 아키텍처가 있습니다.
약간의 XML 구성을 사용하여 IDE의 코어와 플러그인 구현 사이의 접착제 레이어 역할을합니다. 플러그인을 상자 밖으로 찾기,로드 및 버전으로 처리합니다. 새 플러그인 배포는 새로운 XML 구성 파일과 필요한 어셈블리 (DLL)를 간단히 복사하고 응용 프로그램을 다시 시작하는 것이 중요합니다. 원래 저자 (S)의 "CSHARP 응용 프로그램 해부"라는 책 에서이 책에서 더 자세한 내용을 읽을 수 있습니다. 여기. 이 책은 해당 사이트에서 사용할 수있는 것 같지만 여전히 주변에있을 수있는 사본을 찾았습니다. 여기
또한 관련 질문을 찾았습니다 여기
휠을 다시 발명하기보다는 프레임 워크를 사용하십시오. Eclipse 및 NetBeans는 모두 플러그인 기반 확장을 지원합니다. 그래도 Java에서 일해야합니다.