README.md

به نام خدا

آشنایی با اصول شئ‌گرایی (موسوم به اصول SOLID)

افزودن یک روش پیام رسانی دیگر

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

ردیف	محل اعمال تغییرات (کلاس/واسط)	عنوان تغییر	شرحی کوتاه از تغییر
۱	MessageService	افزودن تابع ارسال پیام تلگرامی	افزودن یک تابع void با عنوان sendTelegramMessage
۲	TelegramMessage	افزودن کلاس پیام تلگرام	با فیلدهای آی دی و شماره موبایل برای source و target
۳	TelegramMessageService	افزودن کلاس سرویس پیام تلگرام	ارث بری از واسط MessageService و پیاده سازی متودهای آن
۴	EmailMessageService و SmsMessageService	افزودن متود sendTelegramMessage	پیاده سازی متود جدید با empty body
۵	TelegramMessageService	افزودن متود sendTelegramMessage و validateTelegramId و validatePhoneNumber	پیاده سازی متودهای صحت سنجی شماره موبایل و آی دی و استفاده در عملیات ارسال پیام تلگرام
۶	Main	اضافه کردن گزینه ارسال پیام تلگرام	پیاده سازی کیس جدید برای دریافت شماره موبایل یا آی دی تلگرام برای ارسال پیام
۷	Main	اضافه کردن بررسی کلاس TelegramMessageService	بررسی با instanceof

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

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

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

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

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

اصل مربوطه (از اصول SOLID)	علت نقض	راه حل پیشنهادی
Single Responsibility	گذاشتن توابع در اینترفیس Message که به همه مربوط نمیشود	میتوانیم اینترفیس ها را از هم جدا کنیم تا هر سرویس اینترفیس خود را پیاده سازی کنند. میتوانیم یک تابع sendMessage کلی برای همه بذاریم و هرکس sendMessage خود را پیاده سازی کند
OCP	در MessageService توابع نامربوط به همه ی سرویس ها نهاده شده	اگر یک تابع برای sendMessage در نظر بگیریم، با اضافه کردن یک نوع مسیج دیگر، نیاز به تغییری در این انترفیس نخواهیم داشت
Liskov Substitution Principle	توابع خالی منجر به ارور مبشوند	اگر قسمت قبلی را درست کنیم، این اصل هم حل میشود
ISP	گذاشتن توابع در اینترفیس Message که به همه مربوط نمیشود	میتوانیم اینترفیس ها را از هم جدا کنیم تا هر سرویس اینترفیس خود را پیاده سازی کنند. میتوانیم یک تابع sendMessage کلی برای همه بذاریم و هرکس sendMessage خود را پیاده سازی کند

پاسخ سوالات

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