| شرحی کوتاه از تغییر | عنوان تغییر | محل اعمال تغییرات | ردیف |
|---|---|---|---|
| افزودن کلاس جدید برای ثبت پیامهای تلگرامی | اضافه کردن کلاس پیام تلگرام | TelegramMessage | ۱ |
| افزودن یک تابع void با عنوان sendTelegramMessage که TelegramMessage را ورودی میگیرد. | افزودن تابع ثبت پیام تلگرامی | MessageService | ۲ |
| پیاده سازی تابع با بدنه خالی | پیاده سازی تابع ارسال پیام تلگرام | EmailMessageService | ۳ |
| پیاده سازی تابع با بدنه خالی | پیاده سازی تابع ارسال پیام تلگرام | SNSMessageService | ۴ |
| توابع مربوط به ارسال پیام و ایمیل با بدنه خالی و تابع مربوط به ارسال پیام تلگرام با پیام چاپ مناسب پیاده سازی شدند. | افزودن سرویس پردازش پیامهای تلگرام | TelegramMessageService | ۵ |
| با عدد 3 می توان پیام تلگرام فرستاد | اضافه کردن پیام مربوط به وارد کردن کد مناسب برای تلگرام | main | ۶ |
| شی مربوطه ساخته شده و فیلدهای آن ست شدند. | پیاده سازی قابلیت ثبت پیام تلگرامی | main | ۷ |
| در صورتی که پیام از نوع تلگرامی باشد تابع مناسب فراخوانی شود. | پیاده سازی قابلیت ارسال پیام تلگرامی | main | ۸ |
مجموع تعداد تغییرات: 8
| نقض | تحقق | اصل | ردیف |
|---|---|---|---|
| تمامی کلاس های ارسال پیام دارای توابع خالی سرویس های دیگر نیز هستند و مجبور شده اند آن ها را خالی بگذارند. همچنین می توان گفت که تابع main خیلی از کارها را از جمله دریافت روش ارسال، ساخت پیام و ارسال را انجام می‌دهد که به نظر کار زیادی است. | هر سه سرویسی که برای ارسال پیام از نوع پیامک و ایمیل و تلگرام وجود دارد صرفا توابع مربوط به نوع سفارش خودشان را پیاده سازی کرده اند و با سایر انواع سرویس ها کاری ندارند. | Single responsibility | ۱ |
| برای اضافه کردن روش جدید باید تابع ارسال پیام به آن روش را به واسط قبلی اضافه کنیم. همچنین لازم است تابع main را برای روش جدید بازنویسی کنیم. | می‌توان روش پیام جدید را اضافه کرد و کافی است از کلاس Message ارثبری کند و نیازی به تغییر آن نیست | Open-Close principle(OCP) | ۲ |
| طبق تعریف اصل باید تمامی کلاس های فرزندبا کلاس پدر باید قابلیت جایگزینی داشته باشد. اگر بر فرض مثال MessageService را کلاس پدر در نظر بگیریم و دیگر سرویس ها را کلاس فرزند می توان گفت پدر انتظار دارد تمامی توابع قابلیت عملکرد داشته باشند این در حالی است که همه فرزندان فقط یکی از توابع را پشتیبانی می کنند پس کلاس های فرزند قابلیت تعویض با پدر را ندارند. | در مورد ارتباط انواع پیامها با Message می‌توان آنها را براحتی با کلاس پدر جایگزین کرد و همان عملکردها را دارند. | Liskov Substitution Principle | ۳ |
| طبق این اصل باید گسترش دهندگان یک واسط ملزم به پیاده سازی توابع نامربوط نباشند که در این معماری هر کدام از آنها مجبورند ۲ تابع دیگر را پیاده سازی کنند که آنها را خالی گذاشته اند و این مورد درست نیست و طبق این اصل باید موارد مرتبط را در یک واسط قرار دهیم و cohesion را افزایش دهیم. | این اصل بطور کلی نقض شده است. | Interface Segregation Principle | ۴ |
| در این اصل اشاره شده است که بهتر است حدالامکان از واسط ها بجای خود کلاس های بخصوص پیاده سازی کننده استفاده کنیم ولی این مورد در main به علت پردازش روشهای مختلف ارسال پیام بصورت مجزا دیده نمی‌شود | این مورد رعایت نشده است چونکه وابستگی در سطح کلاسهای concrete است. | Dependency Inversion Principle | ۵ |
| ردیف | اصل | علت نقض | راه حل پیشنهادی |
|---|---|---|---|
| 1 | اصل OCP | هنگام اضافه کردن یک روش جدید ارسال پیام نیاز است کد های قبلی مربوط به روش های قبلی نیز تغییر کند که نقض بسته بودن برای تغییر است. | برای حل این مشکل (و تمام مشکلات دیگر) تمام توابع sendMessage را با هم یکسان میکنیم و با استفاده از چندریختی در هر مدل پیامرسانی آن را به شیوه های مختلف پیاده میکنیم. در نتیجه در واسط MessageService سه تابع موجود را با یک تابع sendMessage جایگزین میکنیم که تنها یک ورودی از جنس Message میگیرد. |
| 2 | اصل LSP | با توجه به اینکه هر سرویس پیام تنها یکی از توابع را پیاده میکند و نه بقیه را، در عمل قابل جایگزینی با کلاس پدر نیستند. چون کلاس پدر توقع دارد که همه عملکرد ها پیاده شده باشند. | همان قبلی |
| 3 | اصل DIP | در کلاس main برای استفاده از سرویس ها در حال استفاده از تابع پیاده سازی هستیم، نه تابع واسط. یعنی برای ارتباط به پیاده سازی رفرنس داده ایم که مخالف این اصل است | همان قبلی |
- تغییرات 2، 3 و 4
- در اینصورت 5 تغییر نیاز است
همانطور که از تعداد تغییرات قابل مشاهده است، زمانی که میخواهیم یک پروژه را توسعه بدهیم و قابلیت های جدید به آن اضافه کنیم، در صورت رعایت اصول سالید کار بسیار ساده تری خواهیم داشت. همچنین رعایت این اصول از تکرار کد های مشابه جلوگیری میکند که باعث میشود میزان کار کمتر و احتمال بروز اشکال پایینتر باشد.