به کانال کلوردوز خوش اومدین
سعی میکنیم چیزایی که بنظر کاربردی هستن رو باهاتون به اشتراک بزاریم
🔥لینوکس
🔥برنامه نویسی فرانت‌اند
🔥برنامه نویسی بک‌اند
🔥اخبار تکنولوژی و...
💢~> @mmdrsdev
Post #1804
2.37K
-اصل Switch Statements در کلین کد
این اصل میگه که کوچیک کردن Switch ها سخته و حتی اونایی که 2 تا case دارن هم تا حدی بزرگ محسوب میشن یسری جاها هم ما مجبوریم ازشون استفاده کنیم برای رفع این مشکل میتونیم از پلی مورفیسم (Polymorphism) استفاده کنیم مثلا کد زیر رو در نظر بگیرید
این کد یه سری مشکلات داره :
اول اینکه بزرگه
دوم اینکه بیشتر از یه کار انجام میده
سوم اینکه اصل اول SOLID رو نقض میکنه چون بیشتر از یه دلیل برای تغییر دادنش دارید
چهارم اینکه اصل دوم SOLID رو هم نقض میکنه چون هربار که type جدید اضافه میشه باید تغییر کنه
اما مشکل اصلی اینه که این ساختار ممکنه تو هزارتا فانکشن دیگه هم نیاز بشه
اما چطور حلش کنیم ؟ (کد توی کامنت رو ببینید ) باید ساختار Switch رو توی یک ABSTRACT FACTORY بزاریم تا بیاد از روی switch برامون گزینه های مناسب مشتقات Employee رو بسازه و توابع مختلف مث calculatePay , isPayDay و deliverPay به صورت پلی مورفیسی از طریق اینترفیس Employee وصل بشن بهش
یعنی ما برای راحت شدن از دست سویچا کاری میکنیم که یه بار بنویسیمشون و چند جا استفاده کنیم
پی نوشت : این اصل کمی طولانی بود و سخت بود توی یه پست توضیحش داد از طرفی توی مثال هاش از شی گرایی اونم توی جاوا استفاده کرده و کارمون تا حدودی سخت تر شد برا همین ممکنه یکم گنگ و سخت شده باشه همین که سعی کنید از سوییچ کمتر استفاده کنید و بتونید کدی بنویسید که از یه سوییچ چند بار استفاده کنید کافیه
#CleanCode
@CleverDevs - @CleverDevsGp
این اصل میگه که کوچیک کردن Switch ها سخته و حتی اونایی که 2 تا case دارن هم تا حدی بزرگ محسوب میشن یسری جاها هم ما مجبوریم ازشون استفاده کنیم برای رفع این مشکل میتونیم از پلی مورفیسم (Polymorphism) استفاده کنیم مثلا کد زیر رو در نظر بگیرید
public Money calculatePay(Employee e)
throws InvalidEmployeeType {
switch (e.type) {
case COMMISSIONED:
return calculateCommissionedPay(e);
case HOURLY:
return calculateHourlyPay(e);
case SALARIED:
return calculateSalariedPay(e);
default:
throw new InvalidEmployeeType(e.type);
}
}
این کد یه سری مشکلات داره :
اول اینکه بزرگه
دوم اینکه بیشتر از یه کار انجام میده
سوم اینکه اصل اول SOLID رو نقض میکنه چون بیشتر از یه دلیل برای تغییر دادنش دارید
چهارم اینکه اصل دوم SOLID رو هم نقض میکنه چون هربار که type جدید اضافه میشه باید تغییر کنه
اما مشکل اصلی اینه که این ساختار ممکنه تو هزارتا فانکشن دیگه هم نیاز بشه
اما چطور حلش کنیم ؟ (کد توی کامنت رو ببینید ) باید ساختار Switch رو توی یک ABSTRACT FACTORY بزاریم تا بیاد از روی switch برامون گزینه های مناسب مشتقات Employee رو بسازه و توابع مختلف مث calculatePay , isPayDay و deliverPay به صورت پلی مورفیسی از طریق اینترفیس Employee وصل بشن بهش
یعنی ما برای راحت شدن از دست سویچا کاری میکنیم که یه بار بنویسیمشون و چند جا استفاده کنیم
پی نوشت : این اصل کمی طولانی بود و سخت بود توی یه پست توضیحش داد از طرفی توی مثال هاش از شی گرایی اونم توی جاوا استفاده کرده و کارمون تا حدودی سخت تر شد برا همین ممکنه یکم گنگ و سخت شده باشه همین که سعی کنید از سوییچ کمتر استفاده کنید و بتونید کدی بنویسید که از یه سوییچ چند بار استفاده کنید کافیه
#CleanCode
@CleverDevs - @CleverDevsGp
- 🔥 9
- 👌 4
- 👍 2
