در توسعه نرم افزار ، طراحی شی گرا هنگام نوشتن کد انعطاف پذیر ، مقیاس پذیر ، حفظ و قابل استفاده مجدد نقش مهمی دارد. مزایای استفاده از OOD بسیار زیاد است اما هر توسعه دهنده نیز باید از اصل جامد برای طراحی خوب شی گرا در برنامه نویسی برخوردار باشد. اصل جامد توسط رابرت سی مارتین ، همچنین به عنوان عمو باب شناخته می شود و این یک استاندارد کدگذاری در برنامه نویسی است. این اصل مخفف پنج اصل است که در زیر آورده شده است ...
- اصل مسئولیت واحد (SRP)
- اصل باز/بسته
- اصل تعویض لیسکوف (LSP)
- اصل تفکیک رابط (ISP)
- اصل وارونگی وابستگی (DIP)
اصل جامد به کاهش جفت محکم کمک می کند. اتصال محکم به این معنی است که گروهی از کلاس ها به یکدیگر وابسته هستند که باید در کد خود از آن جلوگیری کنید. برعکس اتصال اتصال تنگ ، اتصال شل است و کد شما در هنگام داشتن کلاسهای کاملاً مناسب به عنوان یک کد خوب در نظر گرفته می شود. کلاسهای با هم که به راحتی همراه هستند ، تغییرات در کد شما را به حداقل می رسانند ، در ساخت کد قابل استفاده مجدد ، حفظ ، انعطاف پذیر و پایدار کمک می کند. اکنون بیایید یک به یک در مورد این اصول بحث کنیم ...
1. اصل مسئولیت واحد: این اصل بیان می کند که "یک کلاس فقط باید یک دلیل برای تغییر داشته باشد" به این معنی که هر کلاس باید یک مسئولیت واحد یا شغل واحد یا هدف واحد داشته باشد. از توسعه نرم افزار استفاده کنید. این کار به اعضای مختلفی تقسیم می شود که کارهای مختلفی انجام می دهند ، همانطور که طراحان جلوی طراحی می کنند ، تستر آزمایش را انجام می دهد و توسعه دهنده پس زمینه از بخش توسعه پس زمینه مراقبت می کند و می توانیم بگوییم که همه یک شغل یا مسئولیت واحد دارند. بیشتر اوقات اتفاق می افتد که وقتی برنامه نویسان مجبورند ویژگی ها یا رفتار جدیدی را اضافه کنند ، همه چیز را در کلاس موجود اجرا می کنند که کاملاً اشتباه است. این باعث می شود کد آنها طولانی ، پیچیده باشد و زمانی که بعداً نیاز به اصلاح دارد ، زمان مصرف می کند. در برنامه خود از لایه ها استفاده کنید و کلاس های خدا را به کلاس ها یا ماژول های کوچکتر بشکنید.
2. Open/Closed Principle: این اصل بیان می کند که "موجودات نرم افزاری (کلاس ها، ماژول ها، توابع و غیره) باید برای توسعه باز باشند، اما برای اصلاح بسته باشند" به این معنی که شما باید بتوانید یک رفتار کلاس را بدون تغییر آن گسترش دهید.. فرض کنید توسعه‌دهنده A باید یک به‌روزرسانی برای یک کتابخانه یا فریم‌ورک منتشر کند و توسعه‌دهنده B می‌خواهد تغییراتی روی آن ایجاد کند یا ویژگی‌هایی را اضافه کند، سپس توسعه‌دهنده B مجاز است کلاس موجود ایجاد شده توسط توسعه‌دهنده A را گسترش دهد، اما توسعه‌دهنده B قرار نیست کلاس را مستقیماً تغییر دهد.. استفاده از این اصل کد موجود را از کد اصلاح شده جدا می کند، بنابراین ثبات، قابلیت نگهداری بهتر را فراهم می کند و تغییرات را مانند کد شما به حداقل می رساند.
3. اصل جایگزینی لیسکوف: این اصل توسط باربارا لیسکوف در سال 1987 معرفی شد و طبق این اصل "کلاس های مشتق شده یا فرزند باید جایگزین کلاس های پایه یا والد خود شوند". این اصل تضمین می کند که هر کلاسی که فرزند یک کلاس والد است باید به جای والد خود بدون هیچ رفتار غیرمنتظره ای قابل استفاده باشد. شما می توانید این را به گونه ای درک کنید که پسر کشاورز باید مهارت های کشاورزی را از پدرش به ارث برده و در صورت نیاز بتواند جایگزین پدرش شود. اگر پسر بخواهد کشاورز شود، می تواند پدرش را جایگزین کند، اما اگر بخواهد کریکت باز شود، قطعاً پسر نمی تواند جایگزین پدرش شود، حتی اگر هر دو به یک سلسله مراتب خانواده تعلق دارند. یکی از نمونه های کلاسیک این اصل، مستطیلی است که چهار ضلع دارد. ارتفاع مستطیل می تواند هر مقدار و عرض هر مقدار باشد. مربع مستطیلی با عرض و ارتفاع برابر است. بنابراین می توان گفت که می توانیم ویژگی های کلاس مستطیل را به کلاس مربع گسترش دهیم. برای انجام این کار، باید کلاس فرزند (مربع) را با کلاس والد (مستطیل) تعویض کنید تا با تعریف مربعی که چهار ضلع برابر دارد اما کلاس مشتق شده بر رفتار کلاس والد تأثیری نمی‌گذارد، مطابقت داشته باشد. که اصل جایگزینی لیسکوف را نقض می کند. برای درک بهتر، پیوند اصل جایگزینی لیسکوف را بررسی کنید.
4- اصل تفکیک رابط: این اصل اولین اصل است که به جای کلاس ها در جامد در مورد رابط ها اعمال می شود و شبیه به اصل مسئولیت واحد است. این اظهار داشت که "هیچ مشتری را مجبور به اجرای رابط کاربری که برای آنها بی ربط نیست". در اینجا هدف اصلی شما تمرکز بر اجتناب از رابط چربی و اولویت دادن به بسیاری از رابط های خاص مشتری است. شما باید بسیاری از رابط های مشتری را به جای یک رابط کلی ترجیح دهید و هر رابط باید مسئولیت خاصی داشته باشد. فرض کنید اگر وارد رستوران می شوید و گیاهخواری خالص هستید. پیشخدمت در آن رستوران کارت منو را به شما داد که شامل موارد گیاهی ، وسایل غیر گیاهخواری ، نوشیدنی و شیرینی است. در این حالت ، به عنوان مشتری ، شما باید یک کارت منو داشته باشید که فقط موارد گیاهخواری را شامل می شود ، نه همه چیزهایی که در غذای خود نمی خورید. در اینجا منو باید برای انواع مختلف مشتریان متفاوت باشد. کارت منوی مشترک یا عمومی برای همه می تواند به جای فقط یک کارت به چندین کارت تقسیم شود. استفاده از این اصل به کاهش عوارض جانبی و فرکانس تغییرات مورد نیاز کمک می کند.
5- اصل وارونگی وابستگی: قبل از اینکه در مورد این موضوع بحث کنیم ، به خاطر داشته باشید که وارونگی وابستگی و تزریق وابستگی هر دو مفاهیم مختلفی هستند. بیشتر مردم در مورد آن گیج می شوند و فکر می کنند که هر دو یکسان هستند. اکنون دو نکته اصلی در اینجا وجود دارد که باید در مورد این اصل به خاطر بسپارید
- ماژول ها/کلاس های سطح بالا نباید به ماژول ها/کلاس های سطح پایین بستگی داشته باشد. هر دو باید به انتزاع بستگی داشته باشند.
- انتزاع نباید به جزئیات بستگی داشته باشد. جزئیات باید به انتزاع بستگی داشته باشد.
خطوط فوق به سادگی بیان می کنند که اگر یک ماژول یا کلاس بالا به ماژول های سطح پایین یا کلاس وابسته باشد ، کد شما دارای اتصال محکم خواهد بود و اگر سعی کنید در یک کلاس تغییر ایجاد کنید ، می تواند کلاس دیگری را بشکند که خطرناک استدر سطح تولیدبنابراین همیشه سعی کنید کلاس ها را تا آنجا که می توانید به راحتی همراه کنید و می توانید از طریق انتزاع به این هدف برسید. انگیزه اصلی این اصل جدا کردن وابستگی ها است ، بنابراین اگر کلاس A تغییر کند ، کلاس B نیازی به مراقبت یا آگاهی از تغییرات ندارد. می توانید نمونه واقعی باتری از راه دور تلویزیون را در نظر بگیرید. از راه دور شما به باتری احتیاج دارد اما به مارک باتری بستگی ندارد. شما می توانید از هر مارک XYZ که می خواهید استفاده کنید و کار خواهد کرد. بنابراین می توانیم بگوییم که از راه دور تلویزیون به راحتی با نام تجاری همراه است. وارونگی وابستگی باعث می شود کد شما قابل استفاده مجدد باشد.
