اصول جامد در جاوا چیست؟

اصول جامد مفاهیم طراحی شی گرا مربوط به توسعه نرم افزار هستند. Solid یک مخفف برای پنج اصل طراحی کلاس دیگر است: اصل مسئولیت S Ingle ، O اصل بسته بندی شده PEN ، اصل تعویض iskov ، اصل تفکیک من ، و اصل وارونگی حماسه.

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

مثال ها

1. اصل مسئولیت واحد

هر کلاس در جاوا باید یک کار واحد داشته باشد. به طور دقیق ، فقط باید یک دلیل برای تغییر یک کلاس وجود داشته باشد. در اینجا نمونه ای از کلاس جاوا وجود دارد که از اصل مسئولیت واحد (SRP) پیروی نمی کند:

کلاس وسیله نقلیه دارای سه مسئولیت جداگانه است: گزارش ، محاسبه و بانک اطلاعاتی. با استفاده از SRP ، می توانیم کلاس فوق را به سه کلاس با مسئولیت های جداگانه جدا کنیم.

2. اصل بسته بندی شده

اشخاص نرم افزاری (به عنوان مثال ، کلاس ها ، ماژول ها ، توابع) باید برای یک پسوند باز باشند ، اما برای اصلاح بسته شده اند.

روش زیر از محاسبات کلاس کلاس را در نظر بگیرید:

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

اضافه کردن نوع وسیله نقلیه دیگر به آسانی ساخت زیر کلاس دیگر و گسترش از کلاس وسیله نقلیه است.

3. اصل تعویض لیسکوف

اصل جایگزینی Liskov (LSP) در مورد سلسله مراتب وراثت اعمال می شود به گونه ای که کلاسهای مشتق شده باید برای کلاسهای پایه خود کاملاً قابل جایگزین باشند.

یک نمونه معمولی از یک کلاس مشتق شده مربع و کلاس پایه مستطیل را در نظر بگیرید:

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

4- اصل تفکیک رابط

اصل تفکیک رابط (ISP) بیان می کند که مشتریان نباید مجبور شوند به اعضای رابط مورد استفاده آنها وابسته باشند. به عبارت دیگر ، هیچ مشتری را مجبور به اجرای رابط کاربری که برای آنها بی ربط باشد ، مجبور نکنید.

فرض کنید یک رابط کاربری برای وسیله نقلیه و کلاس دوچرخه وجود دارد:

همانطور که مشاهده می کنید ، منطقی نیست که یک کلاس دوچرخه بتواند روش OpenDoors () را پیاده سازی کند زیرا دوچرخه هیچ درهایی ندارد! برای رفع این مشکل ، ISP پیشنهاد می کند که رابط ها به رابط های منسجم کوچک و کوچک تقسیم شوند تا هیچ کلاس مجبور به اجرای هر رابط و بنابراین روش هایی نشود که نیازی به آن ندارد.

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

اصل وارونگی وابستگی (DIP) بیان می کند که ما به جای پیاده سازی های بتونی (کلاس ها) باید به انتزاع (رابط ها و کلاس های انتزاعی) وابسته باشیم. انتزاع نباید به جزئیات بستگی داشته باشد. در عوض ، جزئیات باید به انتزاع بستگی داشته باشد.

مثال زیر را در نظر بگیرید. ما یک کلاس ماشین داریم که به کلاس موتور بتونی بستگی دارد. بنابراین ، از غرق شدن پیروی نمی کند.

در حال حاضر کد کار خواهد کرد ، اما اگر بخواهیم نوع موتور دیگری را اضافه کنیم ، اجازه دهید یک موتور دیزل بگوییم؟این امر به تغییر مجدد کلاس ماشین نیاز دارد. با این حال ، ما می توانیم با معرفی لایه ای از انتزاع ، این مسئله را حل کنیم. به جای اینکه به طور مستقیم به موتور بستگی داشته باشد ، اجازه دهید یک رابط اضافه کنیم:

اکنون می توانیم هر نوع موتور را که رابط موتور را به کلاس اتومبیل پیاده سازی می کند ، وصل کنیم: