اصول SOLID: شناسایی بوی بد کد: Divergent Change - پرسش و پاسخ

پرسش:

بوی بد کد Divergent Change به چه معناست و چگونه در کدنویسی خود را نشان می‌دهد؟

پاسخ:

بوی بد کد Divergent Change زمانی رخ می‌دهد که برای اعمال یک تغییر واحد در نرم‌افزار، مجبور به تغییر چندین کلاس یا ماژول مختلف می‌شویم. این نشان‌دهندهٔ این است که مسئولیت‌های مختلفی در یک کلاس یا ماژول با هم ترکیب شده‌اند و کد به خوبی سازماندهی نشده است.

پرسش:

بوی بد کد 'تغییر واگرا' (Divergent Change) در معماری نرم‌افزار به چه معناست؟

پاسخ:

بوی بد کد 'تغییر واگرا' زمانی رخ می‌دهد که یک کلاس یا ماژول، مسئولیت‌های متعددی دارد و برای اعمال تغییرات در یک جنبه از عملکرد آن، نیاز به تغییر در بخش‌های مختلف آن کلاس یا ماژول باشد. این بدان معناست که یک تغییر در یک قسمت، باعث ایجاد تغییرات ناخواسته در قسمت‌های دیگر می‌شود.

پرسش:

بوی بد کد Divergent Change به چه معناست و چه زمانی در کد رخ می‌دهد؟

پاسخ:

بوی بد کد Divergent Change زمانی رخ می‌دهد که یک کلاس یا ماژول در پاسخ به تغییرات مختلف، از جهات گوناگون، نیاز به اصلاح داشته باشد. به عبارت دیگر، با هر تغییر در یک قابلیت خاص، مجبور به تغییر چندین بخش از یک کلاس می‌شویم.

پرسش:

مثالی از بوی بد کد Divergent Change در دنیای واقعی برنامه‌نویسی چیست؟

پاسخ:

فرض کنید کلاسی به نام 'گزارش‌دهنده' (Reporter) دارید که وظایف مختلفی مانند 'تولید گزارش متنی' (generateTextReport) و 'ارسال گزارش از طریق ایمیل' (sendReportByEmail) را انجام می‌دهد. اگر برای تغییر نحوهٔ قالب‌بندی گزارش متنی، مجبور به تغییر کدی در متد 'تولید گزارش متنی' و همچنین تغییراتی در متد 'ارسال گزارش از طریق ایمیل' (مثلاً برای تطبیق با فرمت جدید) باشید، این یک نمونه از Divergent Change است.

پرسش:

مثالی از بوی بد کد 'تغییر واگرا' در یک سیستم مدیریت سفارشات را شرح دهید.

پاسخ:

فرض کنید کلاسی به نام 'OrderProcessor' وجود دارد که هم مسئول پردازش پرداخت سفارش، هم ارسال ایمیل تأیید و هم ثبت گزارش تراکنش است. اگر بخواهیم روش پرداخت را تغییر دهیم (مثلاً اضافه کردن درگاه پرداخت جدید)، ممکن است مجبور شویم کد مربوط به ارسال ایمیل و ثبت گزارش را نیز دستکاری کنیم، چون همه این‌ها در یک کلاس قرار دارند.

پرسش:

چرا Divergent Change یک بوی بد کد محسوب می‌شود و چه مشکلاتی ایجاد می‌کند؟

پاسخ:

Divergent Change یک بوی بد کد محسوب می‌شود زیرا نشان‌دهندهٔ عدم رعایت اصل مسئولیت واحد (Single Responsibility Principle - SRP) است. این وضعیت باعث می‌شود نگهداری کد دشوار شود، احتمال بروز خطا افزایش یابد و درک کد پیچیده‌تر گردد.

پرسش:

چرا Divergent Change یک بوی بد کد محسوب می‌شود و چه مشکلاتی ایجاد می‌کند؟

پاسخ:

Divergent Change باعث می‌شود نگهداری کد دشوار شود. هر تغییر کوچک نیازمند دستکاری در بخش‌های متعددی از سیستم است که احتمال بروز خطا را افزایش می‌دهد. همچنین، درک کد برای توسعه‌دهندگان جدید سخت‌تر می‌شود زیرا باید چندین نقطه را همزمان در نظر بگیرند.

پرسش:

چرا 'تغییر واگرا' یک بوی بد کد محسوب می‌شود؟

پاسخ:

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

پرسش:

چه مثالی از Divergent Change در برنامه‌نویسی می‌توان ارائه داد؟

پاسخ:

فرض کنید کلاسی به نام Order دارید که هم مسئولیت پردازش سفارش (مانند محاسبهٔ قیمت، اعمال تخفیف) و هم مسئولیت ارسال اعلان (مانند ارسال ایمیل یا پیامک) را بر عهده دارد. اگر بخواهیم نحوهٔ ارسال ایمیل را تغییر دهیم، باید کلاس Order را ویرایش کنیم. اگر بخواهیم منطق محاسبهٔ تخفیف را تغییر دهیم، باز هم باید کلاس Order را ویرایش کنیم. این دو تغییر مستقل هستند اما هر دو منجر به تغییر در یک کلاس می‌شوند.

پرسش:

چگونه می‌توانیم با استفاده از اصل SRP، بوی بد Divergent Change را در مثالی که داده شد، برطرف کنیم؟

پاسخ:

برای رفع بوی بد Divergent Change در مثال 'گزارش‌دهنده'، می‌توانیم کلاس را به دو کلاس مجزا تقسیم کنیم: 'تولیدکننده گزارش' (ReportGenerator) که مسئول تولید قالب‌های مختلف گزارش است و 'سرویس ارسال گزارش' (ReportSender) که مسئول ارسال گزارش‌ها از طریق کانال‌های مختلف (مانند ایمیل) است. با این کار، تغییر در قالب گزارش فقط 'تولیدکننده گزارش' را تحت تأثیر قرار می‌دهد و تغییر در نحوهٔ ارسال، فقط 'سرویس ارسال گزارش' را.

پرسش:

چگونه می‌توان کلاس Order مثال زده شده را با اعمال SRP اصلاح کرد؟

پاسخ:

کلاس Order را می‌توان به دو کلاس مجزا تقسیم کرد: کلاس OrderProcessor که مسئولیت پردازش سفارش را بر عهده دارد و کلاس NotificationSender که مسئولیت ارسال اعلان‌ها را دارد. سپس می‌توان کلاس‌های دیگری برای انواع مختلف اعلان (مانند EmailNotifier, SmsNotifier) ایجاد کرد.

پرسش:

چه اصل SOLID می‌تواند به رفع بوی بد کد 'تغییر واگرا' کمک کند؟

پاسخ:

اصل SOLID که به طور مستقیم به رفع بوی بد کد 'تغییر واگرا' کمک می‌کند، اصل 'تک‌مسئولیتی' (Single Responsibility Principle - SRP) است. این اصل بیان می‌کند که هر کلاس باید تنها یک دلیل برای تغییر داشته باشد.

پرسش:

استفاده از تست‌های واحد (Unit Tests) چگونه می‌تواند در شناسایی و جلوگیری از Divergent Change مؤثر باشد؟

پاسخ:

تست‌های واحد به ما کمک می‌کنند تا وابستگی‌های بین بخش‌های مختلف کد را بهتر درک کنیم. اگر برای تغییر یک قابلیت کوچک، مجبور به بازنویسی یا اصلاح تعداد زیادی تست شویم، این نشانه‌ای از وجود Divergent Change است و به ما در شناسایی آن کمک می‌کند. همچنین، داشتن تست‌های قوی، اطمینان لازم برای تقسیم کلاس‌ها و اعمال تغییرات را فراهم می‌کند.

پرسش:

چگونه با استفاده از اصل تک‌مسئولیتی (SRP) می‌توان بوی بد 'تغییر واگرا' را در مثال OrderProcessor رفع کرد؟

پاسخ:

برای رفع بوی بد 'تغییر واگرا' در مثال OrderProcessor، می‌توان این کلاس را به کلاس‌های کوچک‌تر و تخصصی‌تر تقسیم کرد. به عنوان مثال، یک کلاس 'PaymentProcessor' برای مدیریت پرداخت، یک کلاس 'OrderMailer' برای ارسال ایمیل، و یک کلاس 'TransactionLogger' برای ثبت گزارش تراکنش ایجاد کرد. هر کلاس فقط مسئولیت یک کار را بر عهده خواهد داشت.

پرسش:

چگونه می‌توانیم از بروز Divergent Change در مراحل اولیه طراحی جلوگیری کنیم؟

پاسخ:

با رعایت اصول SOLID از ابتدا، به‌خصوص SRP، و با تفکر در مورد مسئولیت‌های هر کلاس، می‌توان از بروز Divergent Change جلوگیری کرد. استفاده از الگوهای طراحی (Design Patterns) که به جداسازی نگرانی‌ها (Separation of Concerns) کمک می‌کنند نیز مؤثر است.

پرسش:

اگر کلاسی مسئولیت‌های زیادی داشته باشد، چه نشانه‌هایی از 'تغییر واگرا' را می‌توان در آن مشاهده کرد؟

پاسخ:

نشانه‌های 'تغییر واگرا' شامل نیاز به تغییر چندین متد یا بخش از یک کلاس برای انجام یک تغییر منطقی واحد، پیچیدگی غیرضروری در متدها، و دشواری در درک هدف اصلی کلاس به دلیل ترکیب شدن مسئولیت‌های مختلف است.

پرسش:

چگونه می‌توانیم در یک پروژهٔ بزرگ، Divergent Change را شناسایی و مدیریت کنیم؟

پاسخ:

استفاده از ابزارهای تحلیل کد (Code Analysis Tools) که می‌توانند وابستگی بین کلاس‌ها را نشان دهند، می‌تواند به شناسایی الگوهای Divergent Change کمک کند. همچنین، برگزاری جلسات بازبینی کد (Code Review) منظم و تشویق تیم به بحث در مورد ساختار کد و مسئولیت‌ها، در مدیریت این بوی بد کد مؤثر است.

پرسش:

پیامد عدم رفع بوی بد کد 'تغییر واگرا' در طولانی مدت چیست؟

پاسخ:

عدم رفع 'تغییر واگرا' منجر به 'کد کثیف' (Code Rot) می‌شود؛ یعنی کدی که نگهداری آن به شدت دشوار، پرهزینه و مستعد خطا می‌شود. توسعه‌دهندگان جدید برای درک و تغییر آن با مشکل مواجه می‌شوند و احتمال بروز باگ‌های پیش‌بینی نشده افزایش می‌یابد.

پرسش:

چگونه می‌توان با استفاده از الگوهای طراحی (Design Patterns) بوی بد 'تغییر واگرا' را مدیریت کرد؟

پاسخ:

الگوهای طراحی مانند 'استراتژی' (Strategy) یا 'کارخانه' (Factory) می‌توانند به مدیریت 'تغییر واگرا' کمک کنند. این الگوها به ما اجازه می‌دهند تا منطق‌های متغیر را از کلاس‌های اصلی جدا کرده و به کلاس‌های جداگانه منتقل کنیم. به این ترتیب، تغییر در یک جنبه از عملکرد، به جای تغییر کلاس اصلی، تنها نیازمند تغییر در کلاس‌های استراتژی یا کارخانه خواهد بود.

پرسش:

آیا 'تغییر واگرا' همیشه به معنای طراحی ضعیف است؟

پاسخ:

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