وابستگی کامپوننت

در این فصل درباره رابطه بین کامپوننت ها است و یک سری اصل برای آن تعریف میشود. قاعده چرخه وابستگی ها: (اجازه داده نشود که گراف چرخه وابستگی ایجاد شود)

حتمان پیش آمده است که درطول روز روی پروژه کار کرده اید و بعد از ساعت کاری به خانه رفته اید و فردا که دوباره میخواهید روی پروژه کار کنید متوجه میشوید که دیگر کار نمیکند. بدلیل این که افراد دیگری روی پروژه کار میکنند که درحالی که شما در خانه هستید. (صبح بعد از سندرم) این اتفاق در محیط هایی پیش میاید که چندین دولوپر روی یک سورس کد کار میکنند. این مشکل برای پروژه های کوچک زیاد به چشم نمیاید اما وقتی پروژه رشد میکند این مشکل بیشتر دیده میشود و برای حل این مشکل دو راه حل ارائه شده است:

بیلد هفتگی:

این راه حل برای پروژه های با اسکیل متوسط مناسب است این روش به این شکل است که همه دولوپر ها یک کپی از پروژه دارند و کل هفته را روی سورس مخصوص خود کار میکنند و اخر هفته تغییرات خود را یکی میکنند. مزیت عمده ای که این روش دارد این است که دولوپر ها به طور کاملان مستقل از هم کار میکنند. مشکل بدی که در این روش هست یکی کردن کدها است که جریمه یا ضرر بسیاری ایجاد میکند. و به دلیل زمان بر بودن یکی کردن کدها حتی این زمان اخر هفته ممکن است به مرور به جلو برود! بعنوان یک وظیفه چرخه توسعه دربرابر کاست یکی کردن کد, به مراتب بهره وری تیم پایین میآید.درنهایت برای دولوپرها خسته کننده میشود. درنتیجه روش مناسبی نیست.

حدف چرخه های وابستگی:

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

این یک فرایند رابطه ای بسیار ساده است .و به طور گسترده قابل استفاده است برای این که فرایند موفقیت آمیز پیش برود شما میبایست وابستگی ساختار کامپوننت ها را مدیریت کنید. (اونها نمیتوانند به صورت چرخه ای باشند) اگر به این شکل شود سندرم بعد از صبح دوباره اتفاق میآفتد. شکل ۱۴-۱ یک وابستگی بین کامپوننت ها به صورت جهتی کامپوننت ها در یک اپلیکیشن را نشان میدهد.

در این شکل کامپوننت presenter را درنظر بگیرید که یک ریلیز میخواهد ارائه کند.همان طور که مشخص است کامپوننت های view و main تحت تاثیر این ریلیز قرار خواهند گرفت.و آنها تصمیم خواهند گرفت که چه زمانی ریلیز را با کامپوننت خود یکی کنند. در این حین دولوپر های presenters روی کامپوننت خود کار میکنند و نیاز این کامپوننت interactors و entities هست که این ها خودشان هیچ وابستگی دیگری به سیستم ندارند. و کار برای دولوپرهای presenters بسیار ساده است و فقط تعداد کمی وابستگی در کامپوننتشان دارند که میبایست آنها را درنظر داشته باشند.

زمانی که کل سیستم میخواهد دیپلوی شود تکمیل فرایند از پایین به بالا انجام میشود به این شکل که کامپوننت entities اول کامپایل ,تست و ریلیزمیشود و بعد Database و به همین ترتیب بقیه کامپوننت ها. و این روش کاملان شفاف است و هیچ مشکلی وجود ندارد.

اثر یک چرخه وابستگی بر روی گراف وابستگی کامپوننت ها:

یک شرابطی پیش میآید که entities میبایست از کلاس های authorizer استفاده کند مثلان کلاس User از کامپوننت entitites میخواهد از کلاس permission از کامپوننت authorizer استفاده کند. در این حالت با توجه به شکل ۱۴-۲ یک چرخه وابستگی بوجود میآید. در این حالت به عنوان مثال دولوپرهای database برای ریلیز میبایست با کامپوننت entities سازگار باشد. دراینحالت همچنین کامپوننت database باید با کامپوننت authorizer سازگار باشد.اما authorizer به interactor وابسته است. این چرخه کار database را بسیار سخت میکند. این چرخه خودش یه کامپوننت بزرگ را میسازد و همه آن دولوپرهایی که روی کامپوننت های این چرخه کار میکنند به morning after syndrome مواجه میشوند. درنهایت این حد از چفت شدن کامپوننت ها کار را بسیار سخت میکند و مشکلات زیادی بوجود میاورد.

شکستن این چرخه:

برای حل مشکل بالا دو راه حل وجود دارد : ۱-بکار بردن اصل وارونگی وابستگی : در شکل ۱۴-۳ پیاده سازی این اصل را مشاهده میکنید که از یک اینترفیس استفاده شده است. ۲-ساختن یک کامپوننت میانی جدید که کامپوننت های entities و authorizer به آن وابسته باشند.شکل ۱۴-۴

راه حل دوم کاملان شکننده است و وابستگی ها همیشه باید چک شوند و به موقع رفع شوند.