احتمالا در مورد این موضوع شنیده اید که می گویند ما باید تمرکز کنیم که روی کدی که کار میکنیم Coupling کمتر با Cohesion بیشتر داشته باشیم. در این مطلب راجب این موضوع بیشتر صحبت میکنیم و باهم نمونه کد هایی بررسی میکنیم.
در واقع Cohesion تعداد کانکشن های در داخل یک بخش از کد میشود. اگر تعداد Cohesion ما کم باشد احتمال زیاد بخش های مختلف کد ما مرز بندی (boundaries) درستی ندارند و اونا ها رو به درستی از هم جدا نکرده ایم چون در داخل اون بخش کد لاجیک مرتبط به هم وجود ندارد.
از سوی دیگر Coupling نشان دهنده میزان مستقل بودن یک بخش از بخش های دیگر است. تعداد کانکشن بین دو یا چند بخش است. هرچه تعداد کمتر باشد، Coupling کمتر است.
یک بخش میتواند یک متد , یک کلاس , مجموعه ای از کلاس ها و یا یک ماژول باشد. Cohesion و Coupling در سطح های مختلفی قابل بکار گیری هستند.
در اصل Cohesion زیاد به معنی نگه داشتن کنار همدیگر بخش هایی از یک کد هست که به یکدیگر مرتبط هستند آن ها را در یک بخش دسته بندی می کنیم. Coupling کم در مورد این است که این دسته بندی را طوری انجام دهیم که بخش هایی که به هم مربوط نیستند در دسته های مختلف قرار بگیرند در این صورت ارتباط بین بخش های مختلف کم می شود و Coupling ما هم کم می شود.
در تئوری، نحوه کار بسیار ساده به نظر می رسد اما در عمل، باید به مقدار کافی domain model خودمون را بشناسیم تا متوجه بشیم که کدام بخش از کد واقعاً به هم مرتبط هستند.
یعنی که بر خلاف معیارهایی مانند پیچیدگی، میزان Coupling و Cohesion در کد به طور مستقیم قابل اندازه گیری نیست. این به شدت به domain model وابسته هست. رعایت این اصل سخت است به دلیلی این که قابل اندازه گیری نیست.
دایره های همرنگ، بخش هایی از کد مربوط به یکدیگر را نشان می دهند.
زمانی که یک برنامه نویس سعی می‌کند دستورالعمل Coupling کم و Cohesion بالا را پیاده‌سازی کند تلاش زیادی می کند که Coupling را کم کند اما موضوع Cohesion را به طور کامل فراموش می‌کند.
این منجر به وضعیتی می شود که در آن کد decoupled شده است اما در عین حال فوکوس مشخصی در domain model ندارد. اجزای آن به قدری از یکدیگر جدا شده اند که درک مفهوم اون ها خیلی سخت می شود.
به طور مثال این کار است. همانطور که مشاهده می کنید که از یک طرف، کلاس Order کاملاً از Product و حتی OrderLine جدا شده است. منطق محاسبات را به یک interface به نام OrderPriceCalculator واگذار شده است و ایجاد order line توسط یک factory انجام می شود این جداسازی اغلب با دیدگاه "interfaces everywhere" ایجاد می شود. یعنی وسوسه جایگزینی هر class با یک interface، حتی اگر آن واسط نشان دهنده یک انتزاع نباشد.
حالا کد بالا رو چگونه بازنویسی کنیم؟ ما باید ارتباطات بین Order، OrderLine و Product را دوباره مشخص کنیم.
درک رابطه cohesion و coupling مهم است. coupling کامل یک کد بدون آسیب زدن به cohesion ممکن نیست و ایجاد کد کاملاً همراه با cohesion بدون استفاده از coupling غیرممکن است.
تعادل، کلید ایجاد کدی با cohesion بالا و coupling کم است.
بسیاری از توسعه دهندگان در برنامه ای که توسعه می دهند مدل ها فقط برای ذخیره‌سازی برای داده‌هایی هستند که از پایگاه داده به UI منتقل می‌کنند. با استفاده بهتر از مدل ها میتوانیم کد بهتری داشته باشیم.
رسیدن به سطح جدایی که می‌خواهیم در بیشتر موارد ممکن است اما همیشه ممکن نیست. هیچ چیزی نمی تواند جلوی ما را برای ساخت یک مدل تمیز و با cohesion بالا بگیرد.تعداد زیادی از پروژه هایی که شکست میخورند زیر انبوهی از کد های کثیف و اسپاگتی دفن شده اند انقدر این مشکل بزرگ می شود که دیگر برنامه نویس های پروژه نمی توانند فیچر یا تغییرات جدیدی در سیستم بدهند چون هر تغییر مثل دومینو تمام پروژه رو با خطا های ریز و درشت مواجه می کند یکی از مواردی که با رعایت کردنش باعث میشه که پروژه به این سمت نرود رعایت اصل cohesion بالا و coupling کم هست. با رعایت این اصول شما می توانی از فاجعه جلوگیری کنید.
