확장 가능한 소프트웨어 (플러그인 아키텍처)를 설계하는 방법은 무엇입니까?
확장 가능하도록 소프트웨어를 설계하는 방법, 즉 다른 사람들이 기능을 추가하는 추가 기능 / 플러그인을 작성할 수 있도록하는 방법에 대해 설명하는 리소스가 필요합니다.
추천 메뉴가 무엇인가요? 주제에 대해 논의하는 책이 있습니까?
나는 짧고 요점을 선호합니다. 약간의 이론과 많은 구체적인 예.
특정 언어를 대상으로하는 것이 아니라 핵심 아이디어를 이해하여 모든 언어로 구현할 수 있기를 바랍니다.
같은 이유로 다른 사람이 만든 프레임 워크를 사용하지 않는 것을 선호합니다 (프레임 워크가 매우 수준이 높지 않은 경우 (예 : 너무 많이 숨기지 않는 경우 )). 그것을 구현하는 다양한 방법으로 주제와 실험. 또한 프레임 워크는 일반적으로 주제에 대한 사용자의 지식을 가정합니다.
최신 정보
나는 OOP에 대해 묻거나 내 클래스가 상속되도록 허용하지 않습니다. 시스템에 배포 될 응용 프로그램을 설계하는 것에 대해 이야기하고 있습니다. 배포 된 후에 타사 애드온으로 확장 할 수 있습니다.
예를 들어, Notepad ++에는 플러그인 폴더에 .dll 파일을 배치 할 수있는 플러그인 아키텍처가 있으며 여기에 없었던 응용 프로그램에 색상 선택, 스 니펫 삽입 또는 기타 여러 기능을 추가합니다. (다양한 기능).
.NET 을 사용하는 경우 CodeProject 에서 VBScript 를 사용하여 .NET 응용 프로그램을 스크립팅 해보십시오 . 거기에 많은 구체적인 예가 있습니다.
다음은 다양한 응용 프로그램 확장 기술을 구현하는 사이트입니다.
- ClearScript-V8, VBScript 및 JScript를 .NET 앱에서 사용할 수 있도록합니다.
- CS-Script-C # 스크립트 엔진
- C #을 사용한 플러그인 아키텍처
- Opinio 플러그인 아키텍처
- Eclipse 플러그인 아키텍처에 대한 참고 사항
- 초보자를위한 플러그인 아키텍처 프레임 워크
- Gecko 플러그인 아키텍처
- Fungimol 플러그인 아키텍처
OSGI 는 당신이 추구하는 것을 할 수있는 기술 프레임 워크의 좋은 실용적인 예입니다.
확장 성 및 플러그인 작성 기능은 서비스 수명주기를 처리해야합니다.
- 현장에서 서비스 / 플러그인 추가 / 제거
- 서비스 간 종속성 관리
- 서비스 상태 관리 (선언, 설치, 시작, 중지, ...)
모듈의 주요 기능 중 하나는 배포 단위로서 애플리케이션의 기능을 확장하기 위해 빌드하거나 다운로드하고 설치할 수 있습니다.
여기 에서 서비스 의 중심 개념에 대한 좋은 소개 를 찾을 수 있습니다 (귀하의 질문과 관련이 있으며 서비스 와 관련된 몇 가지 문제, 확장 성을위한 핵심 구성 요소).
추출물:
서비스없이 많은 애플리케이션을 구축 할 수 있다면 왜 서비스가 중요할까요? 서비스는 소프트웨어 구성 요소를 서로 분리하는 가장 잘 알려진 방법입니다.
서비스의 가장 중요한 측면 중 하나는 클래스 이름이 아닌 개체의 인스턴스로 작업하기 때문에 클래스로드 문제를 크게 최소화한다는 것입니다. 소비자가 아니라 공급자가 만든 인스턴스입니다. 복잡성의 감소는 매우 놀랍습니다.
서비스는 구성을 최소화 할뿐만 아니라 공유 패키지 수도 크게 줄입니다.
두 가지 경쟁 목표를 달성하려고합니다.
- 소프트웨어의 구성 요소는 자체적 으로 많은 부분 을 노출해야 재사용 할 수 있습니다.
- 소프트웨어의 구성 요소는 자체 노출 이 거의 없어야 재사용 할 수 있습니다.
설명 : 코드 재사용을 장려하려면 기존 클래스를 확장하고 해당 메소드를 호출 할 수 있어야합니다. 메서드가 "private"로 선언되고 클래스가 "final"(확장 할 수 없음) 인 경우에는 불가능합니다. 따라서이 목표를 달성하려면 모든 것이 공개되고 접근 가능해야합니다. 개인 데이터 또는 방법이 없습니다.
소프트웨어의 두 번째 버전을 출시 할 때 버전 1의 많은 아이디어가 잘못되었음을 알게 될 것입니다. 많은 인터페이스 또는 코드, 메서드 이름을 변경하고, 메서드를 삭제하고, API를 중단해야합니다. 이렇게하면 많은 사람들이 외면 할 것입니다. 따라서 소프트웨어를 발전시킬 수 있으려면 구성 요소가 코드 재사용 비용으로 절대적으로 필요하지 않은 것을 노출해서는 안됩니다.
예 : SWT StyledText에서 커서 (캐럿)의 위치를 관찰하고 싶었습니다. 캐럿은 확장되지 않습니다. 이렇게하면 코드에 "org.eclipse.swt 패키지에이 클래스가 있습니까?"와 같은 검사가 포함되어 있으며 많은 메서드가 비공개이며 최종적인 것이 아니라는 것을 알 수 있습니다. 모든 것이 잠겨 있기 때문에이 기능을 구현하기 위해 SWT에서 약 28 개의 클래스를 프로젝트에 복사해야했습니다.
SWT는 사용하기에 좋은 프레임 워크이며 확장하기에는 지옥입니다.
응용 프로그램에서 SOLID 원칙을 구현 하십시오.
1. 단일 책임 원칙 : 클래스는 단일 책임 만 가져야합니다 (즉, 소프트웨어 사양의 잠재적 인 변경 사항 중 하나만 클래스 사양에 영향을 줄 수 있어야합니다.
2. 개방 / 폐쇄 원칙 : 소프트웨어 엔티티 는 확장을 위해 개방 되어야 하지만 수정을 위해 폐쇄 되어야합니다.
3. Liskov 대체 원칙 : 프로그램의 객체는 해당 프로그램의 정확성을 변경하지 않고 하위 유형의 인스턴스로 대체 가능해야합니다.
4. 인터페이스 분리 원칙 : 많은 클라이언트 별 인터페이스가 하나의 범용 인터페이스보다 낫습니다.
5. 의존성 반전 원리 : 추상화에 의존해야합니다 . 결심에 의존하지 마십시오
Stackoverflow 질문 :
물론 유명한 개방 폐쇄 원칙이 있습니다-http: //en.wikipedia.org/wiki/Open/closed_principle
언어에 따라 다릅니다.
- C / C ++에서는 런타임에 라이브러리를 열고 내 보낸 함수를 호출 할 수있는 loadlibrary 함수가 있다고 확신합니다. 이것은 일반적으로 C / C ++에서 수행되는 방식입니다.
- In .NET, there is Reflection, which is offers similar (but more broad) to loadlibrary. There is also entire libraries built on Reflection like Managed Extension Framework, or Mono.Addins that does most of the heavy lifting for you already.
- In Java, there is also Reflection. And there is the JPF (Java Plugin Framework) which is used in stuff like Eclipse IIRC.
Depending on what language you use I could recommend some tutorial/books. I hope this was helpful.
The article Writing Plugin-Based Applications clearly explains the responsibilities of the various parts of the architecture using a very simple example; source code is provided (VB.Net). I found it very helpful in understanding the basic concepts.
Checkout "CAB" - Microsoft's Composition Application Building blocks Framework. I think they've got a "web version" of that too...
I have just started to develop a smart client application. These are two options I am considering.
Using Microsoft's System.AddIn namespace. Looks very promising, however it may be a little complex for our end solution.
Or the Smart Client - Composite UI Application Block from Microsoft
Recently, i have looked at taking components both the Composite UI Application Block and the System.AddIn namespace to build my own. Since source code is available for the CAB it is easy to extend. I think our end solution will be a light weight version of the CAB, definatly using the Unity Application Block
Plugin architecture is becoming very popular for its extensibility and thus flexibility.
For c++, Apache httpd server is actually plugin based, but a concept of module is used instead. Most of apache features are implemented as modules, like cache, rewrite, load balancing, and even threading model. It is a very modular software I ever saw.
And for java, Eclipse is definitely plugin based. The core of Eclipse is an OSGI module system which manage bundles, another concept for plugin. Bundle can provide extension points on which we can build modules with less efforts. The most intricate thing in OSGI is its dynamic characteristic, which means bundles can be installed or uninstalled at runtime. No stop-the-world syndrome any more!
If you work with .Net, our research yielded two approaches: scripting and composition.
Scripting
You extend the functionality of what your classes can do by orchestrating them using scripts. That means exposing what is compiled in your favorite .Net language in a dynamic language.
Some options we found worth exploring:
- IronPython
- IronRuby
- JavaScript: Jint, Jurassic and JavaScript .Net are good starting points.
- Script.Net -> this one was the first one to call our attention.
Composition
If you start a project with .Net 4 or above, you must take a good look at the Managed Extensibility Framework (MEF). It allows you to extend the functionality of your apps in a plugin way.
The Managed Extensibility Framework (MEF) is a composition layer for .NET that improves the flexibility, maintainability and testability of large applications. MEF can be used for third-party plugin extensibility, or it can bring the benefits of a loosely-coupled plugin-like architecture to regular applications.
Managed Add-in Framework is also a good read.
Since I dont have enough rep points to leave a comment, I am posting this as an answer. SharpDevelop is an IDE for developing applications in C#/VB.NET/Boo. It has a pretty impressive architecture that allows itself to be extended in a number of ways - right from new menu items to development support for whole new languages.
It uses a bit of XML configuration to act as a glue layer between a core of the IDE and the plugin implementation. It handles locating, loading and versioning of plugins out of the box. Deploying new plugins is matter of simply copying in the new xml configuration file and the required assemblies (DLLs) and restarting the application. You can read more on this in the book "Dissecting a csharp application" by the original author(s) - Christian Holm, Mike Krüger, Bernhard Spuida of the application from here. The book doesnt seem to be available on that site, but i found a copy that might still be around here
Also found a related question here
Rather than re-inventing the wheel, use the frameworks in hand. Eclipse and Netbeans both support plugin based extensions. You have to work in Java though.
참고URL : https://stackoverflow.com/questions/323202/how-to-design-extensible-software-plugin-architecture
'Nice programing' 카테고리의 다른 글
GraphQL에서 "에지"와 "노드"의 의미는 무엇입니까? (0) | 2020.10.30 |
---|---|
얼굴 인식 API (0) | 2020.10.30 |
AngularJS 인증 + RESTful API (0) | 2020.10.30 |
프로젝트 구성 파일을 처리하는 가장 쉬운 방법은 무엇입니까? (0) | 2020.10.30 |
PHP 코드 리팩토링을위한 도구 (0) | 2020.10.30 |