فراتر از چارچوب: طراحی استراتژی‌های سفارشی تزریق وابستگی برای سیستم‌های نهفته و لبه

در دنیای توسعه دسکتاپ و سمت سرور، چارچوب‌های تزریق وابستگی (DI) مانند Spring، Guice یا کانتینرهای IoC، یک رویه استاندارد هستند. آن‌ها پیچیدگی ساخت گراف اشیاء را پنهان می‌کنند و کد را ماژولار و قابل تست می‌سازند. با این حال، هنگام ورود به حوزه سیستم‌های نهفته و محاسبات لبه، این راه‌حل‌های سنگین اغلب به بار مالیاتی تبدیل می‌شوند. سربار بازتاب (Reflection)، تخصیص پویای حافظه و توالی‌های پیچیده راه‌اندازی می‌تواند در سیستم‌هایی با RAM محدود، نیازمندی‌های سخت‌گیرانه تأخیر یا بدون سیستم‌عامل، غیرقابل قبول باشد.

این مقاله بررسی می‌کند که چگونه استراتژی‌های سفارشی و سبک‌وزن DI را طراحی کنیم که بدون حجم اضافی، ماژولار بودن را حفظ کنند. با بهره‌گیری از حل در زمان کامپایل، مالکیت صریح و انتزاع حداقلی، می‌توانیم مزایای DI را در محیط‌های با منابع محدود به دست آوریم.

مشکلات DI استاندارد در بافت‌های نهفته

کانتینرهای DI سنتی معمولاً به دو مکانیزمی تکیه می‌کنند که برای اهداف نهفته مشکل‌ساز هستند:

• تخصیص پویای حافظه: اکثر کانتینرها اشیاء را روی Heap تخصیص می‌دهند. در سیستم‌های نهفته، تکه‌تکه شدن Heap و غیرقابل پیش‌بینی بودن، ریسک‌های بزرگی هستند.
• بازتاب و متادیتا: اسکن کلاس‌ها برای آnotaionها یا اینترفیس‌ها نیاز به بازرسی در زمان اجرا دارد که در C++ Bare-metal یا غیرممکن است یا از نظر سیکل‌های دستور و حافظه بسیار پرهزینه است.

برای دستگاه‌های لبه، جایی که هر میکروثانیه و هر کیلوبایت اهمیت دارد، به استراتژی DI ای نیاز داریم که ایستا، قطعی و صریح باشد.

استراتژی ۱: تزریق وابستگی در زمان کامپایل

راه‌حل محکم‌ترین برای سیستم‌های نهفته C++، بهره‌گیری از قالب‌ها (Templates) و آنی‌سازی در زمان کامپایل است. این رویه سربار زمان اجرا را به طور کامل حذف می‌کند. وابستگی‌ها در زمان کامپایل حل می‌شوند، که به کامپایلر اجازه می‌دهد کدهای استفاده‌نشده را بهینه‌سازی کند و اطمینان حاصل کند که تخصیص پویا صفر است.

یک `TelemetrySensor` ساده را در نظر بگیرید که به یک `DataLogger` نیاز دارد. به جای تزریق اشاره‌گر در زمان اجرا، وابستگی را از طریق یک پارامتر قالب متصل می‌کنیم:

template <typename Logger>
class TelemetrySensor {
public:
    void read() {
        double value = readHardware();
        logger.log(value);
    }
private:
    Logger logger;
    double readHardware() { /*...*/ }
};

class FileLogger {
public:
    void log(double val) { /*...*/ }
};

// Instantiation is explicit and static
TelemetrySensor<FileLogger> mySensor;

این الگو اطمینان حاصل می‌کند که نوع `Logger` در زمان کامپایل شناخته شده است. گراف اشیاء روی Stack یا در حافظه ایستا ساخته می‌شود و استفاده از Heap را حذف می‌کند. نقطه ضعف آن کاهش انعطاف‌پذیری است؛ شما نمی‌توانید پیاده‌سازی‌ها را در زمان اجرا بدون لینک مجدد باینری تعویض کنید. با این حال، در بسیاری از سناریوهای نهفته، معماری پس از توسعه ثابت است، بنابراین این معامله قابل قبول است.

استراتژی ۲: مکان‌یاب سرویس با ثبت‌نام‌کننده ایستا

وقتی درجه‌ای از انعطاف‌پذیری زمان اجرا نیاز است (مثلاً برای تست یا تعویض داغ پلاگین‌ها)، می‌توان یک مکان‌یاب سرویس سبک‌وزن را بدون بازتاب پیاده‌سازی کرد. به جای اسکن کلاس‌ها، از یک ثبت‌نام‌کننده ایستا استفاده می‌کنیم که در راه‌اندازی پر می‌شود.

class ServiceRegistry {
public:
    template <typename T>
    static void registerService(T* instance) {
        services_[typeid(T).name()] = instance;
    }

    template <typename T>
    static T* getService() {
        auto it = services_.find(typeid(T).name());
        return it != services_.end() ? static_cast<T*>(it->second) : nullptr;
    }

private:
    static std::map<const char*, void*> services_;
};

// Usage
// 1. Create instances in global/static memory
static Logger myLogger;
static TelemetrySensor mySensor;

// 2. Register in init()
void init() {
    ServiceRegistry::registerService(&myLogger);
    ServiceRegistry::registerService(&mySensor);
}

// 3. Access
Logger* log = ServiceRegistry::getService<Logger>();

اگرچه این روش هنوز از `std::map` استفاده می‌کند (که می‌تواند برای کارایی بیشتر با یک آرایه با اندازه ثابت جایگزین شود)، اما از تخصیص پویای خود اشیاء جلوگیری می‌کند. ثبت‌نام‌کننده یک نقطه شکست واحد است، بنابراین باید با احتیاط و فقط برای اینترفیس‌های اصلی و پایدار استفاده شود.

استراتژی ۳: تزریق سازنده با الگوهای کارخانه

برای راه‌حل‌های میانه، تزریق صریح سازنده در ترکیب با توابع کارخانه، یک مسیر تمیز و خوانا ارائه می‌دهد. وابستگی‌ها به طور صریح عبور داده می‌شوند و کارخانه‌ها منطق ایجاد را مدیریت می‌کنند، در حالی که سازنده‌ها تمیز و متمرکز بر راه‌اندازی باقی می‌مانند.

class DataProcessor {
public:
    DataProcessor(ILogger* logger, IConfig* config) 
        : logger_(logger), config_(config) {}
    
    void process() { /*...*/ }

private:
    ILogger* logger_;
    IConfig* config_;
};

// Factory creates the dependency graph
std::unique_ptr<DataProcessor> createProcessor() {
    auto config = std::make_unique<FileConfig>();
    auto logger = std::make_unique<SyslogLogger>();
    
    // Pass raw pointers or use std::shared_ptr if lifetime management is complex
    return std::make_unique<DataProcessor>(logger.get(), config.get());
}

این رویه بسیار قابل تست است. شما می‌توانید پیاده‌سازی‌های Mock از `ILogger` و `IConfig` را در تست‌های واحد تزریق کنید بدون نیاز به راه‌اندازی کامل سیستم. این همچنین وابستگی‌ها را صریح می‌کند که به خوانایی و نگهداری کد کمک می‌کند.

بهترین روش‌ها برای DI نهفته

1. اجتناب از تخصیص پویا: هر جا ممکن است، از آرایه‌های `constexpr`، `std::array` یا ذخیره‌سازی ایستا برای کانتینرهای DI استفاده کنید.
2. حداقل‌سازی توابع مجازی: در مسیرهای حساس به عملکرد، چندشکلی مبتنی بر قالب را بر پخش مجازی ترجیح دهید.
3. مدیریت صریح چرخه عمر: به وضوح تعریف کنید که چه کسی وابستگی‌ها را مالک است و نابود می‌کند. از اشاره‌گرهای آویزان با استفاده از `unique_ptr` یا توالی‌های صریح خاموش شدن اجتناب کنید.
4. تست با فیک‌ها: اینترفیس‌هایی طراحی کنید که Mock کردن آن‌ها آسان باشد. یک استراتژی DI فقط به اندازه قابلیت تست آن خوب است.

نتیجه‌گیری

تزریق وابستگی یک راه‌حل یک‌سایز-برای-همه نیست. در سیستم‌های نهفته و لبه، هدف از راحتی به سمت پیش‌بینی‌پذیری و کارایی تغییر می‌کند. با رها کردن چارچوب‌های سنگین و در آغوش گرفتن حل در زمان کامپایل، ثبت‌نام‌کننده‌های ایستا و تزریق صریح سازنده، توسعه‌دهندگان می‌توانند سیستم‌های ماژولار، قابل تست و پرفرمان بسازند. کلید این است که استراتژی DI را با محدودیت‌های پلتفرم هدف تطبیق دهید و اطمینان حاصل کنید که معماری در خدمت سخت‌افزار است، نه برعکس.