برنامه نویسی کودکان و نوجوانان

طبق اصل باز-بسته، یک کلاس باید برای پسوندها باز باشد، اما برای تغییرات اصول کدنویسی بسته باشد. رفتار یک کلاس ممکن است گسترش یابد اما تغییر نکند. این اصل کمک می کند تا از خطا در قسمت های کد از قبل تکمیل شده جلوگیری شود. اگر یک برنامه افزودنی فقط با ایجاد تغییرات در یک کلاس قابل دستیابی باشد، خطر این که تغییرات منجر به دریافت خطاهای جدید توابع کاملاً پیاده‌سازی شده شود، بسیار زیاد است.

اصل باز-بسته معمولاً از دو طریق قابل دستیابی است: ارث بردن و استفاده از رابط. با رعایت این اصل اصول کدنویسی ، می توان توابع جدیدی را بدون تغییر کلاسهای موجود به یک برنامه اضافه کرد.

کتابخانه C (غیر شی گرا) قبلاً شامل نمونه هایی از این اصل است، به عنوان مثال اجرای تابع مرتب سازی سریع:

 رای اینکه بتوانید نوع داده خود را مرتب کنید، تابع qsort لازم نیست بازنویسی شود. الگوریتم همیشه ثابت می ماند. کاربر فقط باید تابع مقایسه خود را به الگوریتم منتقل کند. این بدان معنی است که می توان آن را بدون نیاز به تغییر الگوریتم گسترش داد.

اصل جایگزینی لیسکوف

اصل جایگزینی لیسکوف ایجاب می کند که کلاسهای مشتق شده همیشه باید به جای کلاس اصلی خود قابل استفاده باشند. زیرگروه ها باید مانند نوع پایه خود رفتار کنند. این واضح به نظر می رسد، اما آیا این است؟ کامپایلر می داند که یک کلاس مشتق شده نیز از نوع کلاس پایه است - یعنی همیشه می توان آن را به آن تبدیل کرد. آیا این اصول کدنویسی کافی است؟

اصل جایگزینی لیسکوف فراتر از کامپایلر است.

اگر یک متد انتظار پارامتری از نوع Base را داشته باشد (شکل 1 را ببینید)، برای مثال public void TuWasTolles (Base b)، هیچ تفاوتی ندارد که یک شی از نوع Base یا از نوع مشتق شده Derived ارسال شود. در کلاس Derived باید اطمینان حاصل شود که رفتار از دیدگاه متد TuWasTolles () مانند کلاس Base است. به عنوان مثال ، اگر روش کلاس پایه هیچ استثنائی ایرانیان سایبر ایجاد نکند ، روش کلاس مشتق شده نیز نمی تواند استثنا را پرتاب کند.

یک کلاس مشتق شده ممکن است کلاس پایه خود را گسترش دهد، اما آن را محدود یا تغییر ندهد. متأسفانه، این اصل اغلب نادیده گرفته می شود. تست های واحد می توانند اطمینان حاصل کنند که نقض اصول کدنویسی اصل جایگزینی لیسکوف به طور تصادفی در نرم افزار ساخته نشده است.

اصل جداسازی رابط

اصل جداسازی رابط بیان می کند که یک کلاینت نباید به عملکردهای سروری که اصلاً به آن نیاز ندارد وابسته باشد. این بدان معناست که یک رابط ممکن است فقط شامل توابع باشد که واقعاً به هم تعلق دارند. مشکل این است که رابط‌های «چربی» بین کلاینت‌های مستقل ایجاد می‌کنند.

 اگر یکی از جنبه های رابط تغییر کند، این روی همه مشتریان تأثیر می گذارد - حتی اگر آنها از این جنبه استفاده نکنند.

یک مثال واضح توسط کتابخانه Java AWT ارائه شده است: اگر قرار است فقط به رویداد بسته شدن پنجره واکنش نشان داده شود، تمام روش های رابط WindowListener باید پیاده سازی شوند (شکل 2).

وقتی چنین رابطی در دسترس باشد و قابل تغییر نباشد چه می توان کرد؟ اصول کدنویسی می توان از آداپتور استفاده کرد (الگوی طراحی آداپتور). این آداپتور تمام روش های رابط را با پیاده سازی ساختگی پیاده سازی می کند و آنها را به صورت مجازی در دسترس قرار می دهد.

در اینجا نیز کتابخانه Java AWT به عنوان مثال عمل می کند. این چنین آداپتوری را برای مثال نشان داده شده در بالا فراهم می کند.

اصل وارونگی وابستگی

اصل وارونگی وابستگی بیان می کند که کلاسهای سطح انتزاعی بالاتر نباید وابسته به کلاسهای سطح انتزاعی پایین باشند. اما موضوع صرفاً معکوس کردن وابستگی ها نیست. دیگر نباید هیچ گونه وابستگی بین کلاس ها وجود داشته باشد. فقط باید وابستگی به رابط ها (هر دو طرف) وجود داشته باشد.

رابط ها نباید به جزئیات وابسته باشند، بلکه باید به جزئیات رابط ها وابسته باشند.

مثال: کلاس های شکل 4 بسیار قوی به یکدیگر مرتبط هستند. وابستگی ها بسیار قوی هستند k اینکه تست جداگانه یک کلاس بدون تغییر کد امکان پذیر نیست. اعمال تغییرات در الزامات نیز به دلیل این اتصال قوی ، دشوارتر است.

یک پیشنهاد برای راه حل - پارامترهای سازنده

Aggregation با تداعی جایگزین می شود و وابستگی اصول کدنویسی  به یک کلاس خاص به وابستگی به یک رابط تغییر می کند (شکل 5). شی بتن (از کلاس Logger) به عنوان یک پارامتر به سازنده کلاس Bank ارسال می شود. این یک راه حل بسیار ساده، اما فقط تا حدی انعطاف پذیر است. اصول SOLID - پنج اصل برای نرم افزار بهتر

کیفیت نرم افزار در همه پروژه ها ایده آل نیست. استفاده از مهندسی نرم افزار برای بهبود کد درقواعد کدنویسی  تمام جنبه های آن در نظر گرفته شده است. با این پنج اصل به هدف نزدیکتر خواهید شد. زیرا کد خوب انگیزه اصول کدنویسی می دهد!