Experiment-SOLID

گام ۱: افزودن یک روش سفارش و پرداخت تلفنی

تغییراتی را که در کد فعلی برنامه می‌دهید، در جدول زیر ثبت کنید و در نهایت تعداد کل تغییرات را اعلان کنید.
- توجه: مواردی که به عنوان تغییرات باید اعلان شود شامل این موارد هستند:
  1. ساخت کلاس جدید
  2. افزودن تابع جدید به کلاس و یا واسط (برای توابع جدید صرفا اعلام تغییر کنید)
  3. هر خطوط پیاپی‌ای که در تابع main و برای افزودن یک قابلیت جدید اضافه می‌کنید. به عنوان مثال اگر سه خط را به منظور تشخیص نوع پیام اضافه می‌کنید، آن سه خط را در قالب یک تغییر اعلام کنید (البته جزییات آن را در ستون «شرحی کوتاه از تغییر» توضیح دهید).

ردیف	محل اعمال تغییرات (کلاس/واسط)	عنوان تغییر	شرحی کوتاه از تغییر
۱	OrderService	افزودن تابع پرداخت تلفنی	افزودن یک تابع void با عنوان phoneOrderPayment
۲	OrderService	افزودن تابع ثبت سفارش تلفنی	افزودن یک تابع void با عنوان phoneOrderRegister
۳	PhoneOrderService	ساخت کلاس جدید پرداخت و ثبت سفارش تلفنی	ساخت کلاس جدید که از OrderService ارث‌بری می‌کند و توابع مربوط به سفارش تلفنی یک پرینت ساده انجام می‌دهند.
۴	OnlineOrderService	اضافه کردن تابع phoneOrderPayment	تابع ثبت سفارش به روش تلفنی با بدنه ی خالی به کلاس اضافه شد.
۵	OnlineOrderService	اضافه کردن تابع phoneOrderRegister	تابع پرداخت سفارش به روش تلفنی با بدنه ی خالی به کلاس اضافه شد.
۶	OnsiteOrderService	اضافه کردن تابع phoneOrderPayment	تابع ثبت سفارش به روش تلفنی با بدنه ی خالی به کلاس اضافه شد.
۷	OnsiteOrderService	اضافه کردن تابع phoneOrderRegister	تابع پرداخت سفارش به روش تلفنی با بدنه ی خالی به کلاس اضافه شد.
۸	Main	افزودن روش ثبت سفارش تلفنی با شماره ۳	اضافه کردن یک شرط برای چک کردن این که روش ثبت سفارش تلفنی است یا خیر.
۹	Main	افزودن روش پرداخت تلفنی	اضافه کردن یک شرط برای چک کردن این که اگر روش ثبت سفارش تلفنی است پرداخت نیز تلفنی باشد./p>

مجموع تعداد تغییرات: ۹

گام ۲: تحلیل و وارسی برنامه از منظر تحقق و یا عدم تحقق اصول SOLID

در خصوص این برنامه‌ای که نوشته شده بود و شما یک قابلیت به آن اضافه کردید، بر اساس اصول SOLID موارد نقض و یا محقق شدن هر کدام از آن اصول را بیان کنید. در بیان موارد تحقق و نقض، علت تحقق و یا نقض را نیز به صورت کامل توضیح دهید:

اصل 1 Single Responsibility	موارد تحقق	نابع main میتوان گفت دقیقا همین موضوع را نشان میدهد و کلاس Message نیز به این صورت است.
	موارد نقض
اصل 2 Open-Close Principle (OCP)	موارد تحقق	کلاس Main به این اصل را برآورده می‌کند و برای اضافه کردن قابلیت جدید نیاز به تغییر زیاد در آن نبود.
	موارد نقض	در کلاس orderService این اصل به وضوح نقض می‌شود. در هنگام اضافه کردن تماس تلفنی، هم باید خود orderService را تغییر داد و هم تمام کلاس‌های زیرمجموعه آن را باید تغییر داد و توابع با بدنه خالی به آنها اضافه کرد.
اصل 3 Liskov Substitution Principle	موارد تحقق	بین کلاس‌های مربوط به orderService ارث‌بری به شکل درست برقرار است و رابطه is-a بین کلاس orderService و باقی زیر کلاس‌های آن وجود دارد.
	موارد نقض
اصل 4 Interface Segregation Principle	موارد تحقق
	موارد نقض	در کلاس OrderService تمام توابع زیرکلاس‌ها قرار گرفته‌اند که باعث می‌شود مجبور شویم در زیر‌کلاس‌ها، توابع خالی قرار دهیم.
اصل 5 Dependency Inversion Principle	موارد تحقق	کلاس orderService بر پایه همین اصل است.
	موارد نقض	با وجود کلاس orderService، همچنان در استفاده از روش‌های مختلف این واسطه‌گری به درسنی انجام نمی‌شود. در کلاس Main مجبور هستیم هر روش رو به شکل جداگانه فراخوانی کنیم. اگر این تفکیک در سمت یک کلاس واسط انجام شود بهتر است.

در خصوص هرکدام از موارد نقض هرکدام از اصول، یک راهکار را به منظور رفع آن مشکل ارایه داده و در جدول زیر ثبت نمایید:

اصل مربوطه (از اصول SOLID)	علت نقض	راه حل پیشنهادی
OCP	در کلاس orderService این اصل به وضوح نقض می‌شود. در هنگام اضافه کردن تماس تلفنی، هم باید خود orderService را تغییر داد و هم تمام کلاس‌های زیرمجموعه آن را باید تغییر داد و توابع با بدنه خالی به آنها اضافه کرد.	در کلاس orderService به شکل کلی دو تابع برای ثبت و پرداخت سفارش قرار می‌دهیم و در باقی کلاس ها این توابع را بازنویسی می‌کنیم.
ISP	در کلاس OrderService تمام توابع زیرکلاس‌ها قرار گرفته‌اند که باعث می‌شود مجبور شویم در زیر‌کلاس‌ها، توابع خالی قرار دهیم.	در کلاس orderService به شکل کلی دو تابع برای ثبت و پرداخت سفارش قرار می‌دهیم و در باقی کلاس ها این توابع را بازنویسی می‌کنیم.
DIP	با وجود کلاس orderService، همچنان در استفاده از روش‌های مختلف این واسطه‌گری به درسنی انجام نمی‌شود. در کلاس Main مجبور هستیم هر روش رو به شکل جداگانه فراخوانی کنیم.	یک کلاس واسط ایجاد می‌کنیم که این تفکیک را انجام دهد.

گام ۳: اصلاح موارد نقض

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

گام ۴: بررسی مجدد تغییرات مورد نیاز

فرض کنید که گام 1 را برای کد اصلاح شده (پس از انجام گام‌های ۲ و ۳) اجرا کرده‌اید.

1. در این صورت از انجام کدام یک از تغییرات ثبت شده در جدول گام ۱ معاف خواهید شد؟

با توجه به اصلاحات انجام شده در گام ۲ و ۳، اکنون ساختار برنامه باید به گونه‌ای باشد که اصل Open-Close Principle (OCP) و Interface Segregation Principle (ISP) رعایت شده باشد. به این ترتیب، هنگام افزودن روش سفارش و پرداخت تلفنی، نیاز به تغییر در واسط‌های موجود نخواهد بود، زیرا هر کلاس واسط خودش را دارد و تغییرات جدید باید در کلاس‌های جدیدی انجام شوند که از این واسط‌ها ارث‌بری می‌کنند. ه دلیل اینکه کلاس‌های واسط به درستی طراحی شده‌اند، نیازی به افزودن توابع خالی در کلاس‌های دیگر نخواهد بود. بنابراین، از تغییرات ۴ تا ۷ که شامل اضافه کردن توابع خالی در کلاس‌های دیگر (OnlineOrderService و OnsiteOrderService) بودند، معاف خواهیم شد.

2. تعداد تغییرات مورد نیاز، چند تغییر خواهد شد؟ با توجه به اصلاحات انجام شده بر اساس اصول SOLID، تعداد تغییرات مورد نیاز به شرح زیر خواهد بود:

اایجاد کلاس جدید PhoneOrderService و پیاده‌سازی توابع مربوط به سفارش و پرداخت تلفنی (تغییرات ۱ و ۲ و ۳ در جدول اصلی). تغییرات مربوط به تابع main برای افزودن روش سفارش و پرداخت تلفنی (تغییرات ۸ و ۹ در جدول اصلی). بنابراین، تعداد تغییرات مورد نیاز در مجموع ۴ تغییر خواهد بود.

گام ۵: جمع بندی

در این بخش، بیان کنید که از این گام چه نتیجه‌ای گرفته‌اید؟ و به نظر شما به کارگیری صحیح اصول SOLID در گام‌های ۳ و ۴ چه مزایایی را نسبت به حالتی دارد که این اصول رعایت نشده‌بود؟

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

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

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

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