Thiết kế phần mềm dựa trên trình cắm

Tôi là một nhà phát triển phần mềm, người sẵn sàng cải thiện kỹ năng thiết kế phần mềm của mình. Tôi nghĩ phần mềm không chỉ hoạt động mà còn có thiết kế chắc chắn và thanh lịch để có thể tái sử dụng và mở rộng cho các mục đích sau này.

Bây giờ tôi đang tìm kiếm một số trợ giúp để tìm ra các thực tiễn tốt cho các vấn đề cụ thể. Trên thực tế, tôi đang cố gắng tìm hiểu cách thiết kế một phần mềm có thể mở rộng thông qua các trình cắm.

Các câu hỏi tôi có như sau:

• Các plugin có thể truy cập chức năng của nhau không? Điều này sẽ mang lại sự phụ thuộc tôi đoán.
• Ứng dụng chính sẽ cung cấp những gì cho các plugin nếu tôi muốn nói rằng hãy phát triển một phần mềm đa phương tiện có thể phát video và nhạc nhưng sau này có thể có chức năng được thêm vào các plugin để có thể đọc trạng thái video ( thời gian, bps, ...) và hiển thị nó. Điều này có nghĩa là chính người chơi sẽ phải là một phần của chương trình chính và cung cấp dịch vụ cho các trình cắm để có được thông tin đó hoặc sẽ có cách để phát triển trình phát dưới dạng trình cắm nhưng cũng có thể cung cấp theo cách nào đó để các plugin khác tương tác với nó?

Như bạn thấy, các câu hỏi của tôi chủ yếu dành cho mục đích học tập khi tôi cố gắng cải thiện các kỹ năng phát triển phần mềm của mình.

Tôi hy vọng sẽ tìm thấy sự giúp đỡ ở đây và xin lỗi nếu có gì đó không ổn với câu hỏi của tôi.

Khá nhiều phần mềm "muốn" được mở rộng theo thời gian, bởi nhiều người đóng góp không được liên kết hoặc phối hợp chặt chẽ, có thể được hưởng lợi từ một kiến trúc trình cắm nào đó. Ví dụ phổ biến là hệ điều hành, công cụ CAD và GIS, công cụ xử lý hình ảnh và vẽ, trình soạn thảo văn bản và trình xử lý văn bản, IDE, trình duyệt web, hệ thống quản lý nội dung web và ngôn ngữ lập trình và khung. Plugin là nền tảng chính của các hệ thống mở rộng.

Kiến trúc trình cắm thường sử dụng gõ vịt . Các kiến trúc sư định nghĩa một tập phổ biến của phương pháp (ví dụ open, close, play, stop, seek, vv), mà mỗi plug-in sau đó dụng cụ (hoặc hoàn toàn hoặc một phần). Một số phương pháp là bắt buộc, trong khi các phương pháp khác có thể là tùy chọn hoặc chỉ hữu ích trong các trường hợp cụ thể.

Khi chương trình chính ban đầu chạy, nó sẽ kiểm tra một hoặc nhiều "khu vực plugin" (chẳng hạn như các ./pluginsthư mục đã biết ) về sự tồn tại của các plugin. Những người tìm thấy được tải vào chương trình.

Thông thường các plugin phải tồn tại tại thời điểm chương trình chính chạy. Hạt nhân Unix và máy chủ web Apache thường hoạt động theo cách này; chúng phải được khởi động lại để "nhìn" và sử dụng các plugin mới. Plugin có thể năng động hơn tuy nhiên; ở đây chương trình chính kiểm tra lại định kỳ các plugin mới được thêm hoặc thay đổi (ví dụ: bằng cách so sánh plugins-last-loadeddấu thời gian được lưu trữ với dấu thời gian "được sửa đổi lần cuối" cho thư mục plugin). Chương trình chính sau đó sẽ (tải lại) các plugin - hoặc tất cả chúng, trong trường hợp đơn giản / ngây thơ, hoặc chỉ những cái mới / đã thay đổi, nếu nó phức tạp hơn.

Thường có một yêu cầu "đăng ký", với mỗi plugin không chỉ là mã, mà còn bao gồm một số siêu dữ liệu truyền đạt cách thức plugin tích hợp vào toàn bộ. Ví dụ, một trình phát nhạc, có thể được yêu cầu để nói loại tệp nào có thể phát, loại kiến ​​trúc bộ xử lý nào có thể chạy, tài nguyên nào cần (ví dụ: cần phân bổ bao nhiêu bộ nhớ) và các thuộc tính khác cần thiết cho chương trình chính để quyết định sử dụng plugin nào để phát tệp nào.

Các cơ chế đăng ký, tải và tương tác với chương trình chính khá đặc biệt về ngôn ngữ và khung. Bởi vì có rất nhiều "sự phối hợp" đang diễn ra, với một số chức năng được xử lý bởi chương trình chính và một số bởi các plugin của nó (trong đó có thể có một vài), để thiết lập một chương trình mở rộng đòi hỏi phải quan tâm và xem xét, và một cái nhìn kiến ​​trúc của chương trình là "một hệ thống" chứ không phải là "một đoạn mã".

Hầu hết các dự án quy mô lớn sẽ chọn khung plugin hoặc thiết kế riêng. Ngoài ra còn có một số khung plugin chung được thiết kế để đơn giản hóa việc biến chương trình của bạn thành một hệ thống mở rộng.

(Trả lời Câu hỏi 1) Mặc dù các trình cắm có thể sử dụng chức năng của nhau, nhưng chúng thường sẽ làm như vậy thông qua các phương thức / API được xác định trước mà kiến ​​trúc sư đưa ra. Việc sử dụng "gõ vịt" như vậy giúp tránh sự phụ thuộc lẫn nhau và có nghĩa là không nhất thiết phải rõ liệu một tính năng nhất định được cung cấp bởi mã "lõi" hay plugin. Thật vậy, khi áp dụng chiến lược bổ trợ, nhiều nhà phát triển triển khai các tính năng "cốt lõi" như các plugin - chỉ là các tính năng được cung cấp cùng với chương trình chính. Mặc dù có các chuỗi bổ trợ spaghetti không lý tưởng, nhưng không có gì lạ khi thấy một số plugin yêu cầu sự tồn tại của các plugin khác.

(Câu trả lời cho câu hỏi 2) Là một kiến trúc sư, điều chính bạn cung cấp plug-in là một kiến trúc - ví dụ như một tập hợp các phương pháp thông qua đó họ được thiết lập, đăng ký, và gọi, và một thiết kế và thiết lập các yêu cầu, trong đó bổ sung sẽ hoạt động . Chương trình chính, trong khi chạy, thường hiển thị nhiều nếu không phải tất cả các cấu trúc dữ liệu bên trong và phương thức của nó cho các plugin. Đây rõ ràng là một tiếp xúc an ninh. Một số kỹ thuật hộp cát có thể được sử dụng (và ngày càng được sử dụng), nhưng thông thường nhất, các plugin là mã "đáng tin cậy", hoạt động như thể chúng là một phần của chương trình chính.

Để đọc thêm:

• Trang trình cắm của Wikipedia đáng để nghiên cứu.
• Một hướng dẫn tốt về cách bạn có thể làm cho một trình soạn thảo có thể mở rộng bằng cách sử dụng khung plugin Yapsy.
• Giải thích về hệ thống trình cắm thêm xương trần cho Python