Skip to content

Latest commit

 

History

History
338 lines (319 loc) · 10.7 KB

README.md

File metadata and controls

338 lines (319 loc) · 10.7 KB

به نام خدا

آشنایی با اصول شئ‌گرایی (موسوم به اصول 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. رعایت اصول شی‌ گرایی، کد را خواناتر، قابل نگهداری و توسعه‌پذیر می‌کند، به‌طوری‌ ‌که افزودن ویژگی‌ های جدید به‌ راحتی و بدون تغییرات عمده در کد موجود امکان‌ پذیر است. همچنین، کد با انعطاف‌ پذیری بیشتر و کاهش وابستگی‌ ها، بهبود تست‌ پذیری و کاهش احتمال بروز خطا را فراهم می‌کند.