اصل اول: Encapsulate what varies
"آنچه را که تغییر میکند مشخص و جدا کن یا به عبارتی آنرا کپسوله کن"
برای آنکه بتوانیم کدی منعطف، قابل استفاده مجدد و خوانا داشته باشیم، ابتدا باید بخشهای ثابت و متغیر کد را تشخیص دهیم و کاری کنیم تا بخش ثابت، بدون تکرار در جای جای برنامه استفاده شود و سپس برای بخش متغیر برنامه ریزی کنیم.
اصل دوم: Program to an interface not implementation
"برنامه نویسی را متمرکز بر واسط کن، نه نحوهی پیاده سازی"
برای این اصل تعابیر مختلفی ارائه شده است:
- تمرکز بر واسطها به معنای تمرکز بر رفتار است که باعث میشود انعطاف برنامه بیشتر شده و با تغییر نحوهی پیاده سازی بتوان همچنان سیستمی پایدار داشت.
- تمرکز بر "چه کاری انجام میشود" باعث میشود بدون نگرانی از "چگونگی انجام آن" بتوانیم معماری سیستم را طراحی کنیم.
- واسطها نقش پروتکل را دارند و باعث پنهان شدن نحوهی پیاده سازی از چشم کلاینت (استفاده کنندهی خدمت) میشوند و آنها را ملزم میکنند تا به ورودی و خروجی تمرکز کنند.
برای رعایت این اصل باید:
- سعی بر تعریف واسط برای اکثر کلاسها کنیم
- اشیا را از نوع واسط تعریف کنیم، نه کلاسهای پیاده ساز آن
اصل سوم: Favor composition over inheritance
"ترکیب را بر توارث ترجیح بده"
رابطه "دارد" (has a ) انعطاف بیشتری نسبت به ارث بری یا "از نوع ... هست" ( is a ) دارد. برای مثال فرض کنید کلاس Enemy رفتار Movable را دارد و این رفتار در طول بازی بر حسب موقعیتی تغییر میکند. اگر این رفتار را با توارث مدل کنیم، یعنی Enemy از نوع Movable باشد، آنگاه برای هر نوع رفتار Movable (هر نوع پیاده سازی) باید یک نوع Enemy داشته باشیم و تصور کنید بعضی از این پیاده سازیها در کلاس Player یکسان باشد. آنگاه کد باید دوباره تکرار شود. حال تصور کنید این موقعیت را با ترکیب مدل کنیم. آنگاه کلاس Enemy یک شیء از جنس Movable خواهد داشت و در زمان نیاز میتواند نوع این رفتار را با نمونه گیری از کلاسهای پیاده ساز آن، تغییر دهد. در واقع با اینکار اصل اول را رعایت کرده ایم و بخش ثابت را از بخش متغیر جدا نموده ایم.
اصل چهارم: Starve for loosely coupled designs
"به دنبال طراحی با اتصال سست بین اجزا باش"
اتصال بین اجزای برنامه نویسی باعث سختتر شدن مدیریت تغییرات میشود، چرا که با تغییر یک بخش، بخشهای متصل نیز دچار مشکل خواهند شد. اتصالها از لحاظ نوع قدرت متفاوتند و اساسا سیستمی بدون اتصال وجود ندارد. لذا باید به دنبال یک طراحی با کمترین میزان قدرت اتصال یا همان سست اتصال باشیم.
تا به اینجا، اصلهای دوم و سوم ما را در کاهش وابستگی و اتصال قوی کمک کردهاند. استفاده از واسطها، باعث کاهش وابستگی به نوع پیاده سازی میشود. استفاده از ترکیب نیز به نوعی باعث از بین رفتن وابستگی قوی بین کلاسهای فرزند و کلاس والد میشود و با روشی دیگر (استفاده از شیء در برگرفته شده برای پیاده سازی وظیفهی تغییر کننده) وظایف را در کلاسها پیاده سازی میکند.
KISS
قاعده Keep it simple stupid بیان می کند که به ساده ترین شکل ممکن کد بزنید. در حقیقت یکی از مشکلات رایج در طراحی نرم افزار، حل مسائل از روش های پیچیده است در حالی که می توان با روش ساده تر آن کار را انجام داد.
Tell, Don’t Ask
این قاعده بیان کننده اصل بسته بندی در شیءگرایی است. بیان به کلاس های بگوییم که چه چیزی از آنها می خواهیم نه اینکه از وضعیت درونی آن سوال کنیم و سپس تصمیم بگیریم که چه چکاری را انجام دهند. این اصل باعث تنظیم مسئولیت های هر کلاس می گردد و از چسبیدگی کلاس ها به یکدیگر جلوگیری می کند.
YAGNI
قاعده You ain’t gonna need it میگوید که آنقدر کد بزنید که لازم است نه بیشتر. این قاعده در توسعه تست محور[1] نقش بسیار مهمی دارد. نباید بر اساس تصورات در آینده و هر دلیلی غیر از ضرورت در حال حاضر، کد اضافه به برنامه وارد گردد.
SoC
قاعده Seperation of Concern عبارت است از دسته بندی کردن کد برنامه بر اساس کارکردشان. معماری لایهای یک نمونه عالی از اعمال SoC است. جداسازی برنامه به مسئولیتهای جدا از هم نقش مهمی در استفاده مجدد، نگهداری و تست پذیری سیستم دارد.