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

  • اصل مسئولیت واحد (SRP)
  • اصل باز/بسته
  • اصل جایگزینی لیسکوف (LSP)
  • اصل جداسازی رابط (ISP)
  • اصل وارونگی وابستگی (DIP)

اصول سالید

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

  • اصل مسئولیت واحد

این اصل بیان می کند که "یک طبقه باید فقط یک دلیل برای تغییر داشته باشد" به این معنی که هر طبقه باید یک مسئولیت یا شغل یا هدف واحد داشته باشد. به عنوان مثال توسعه نرم افزار را در نظر بگیرید. این وظیفه به اعضای مختلف تقسیم می شود که کارهای مختلفی را انجام می دهند، همانطور که طراحان جلویی طراحی می کنند، تستر تست انجام می دهد و توسعه دهنده بک اند از قسمت توسعه باطن مراقبت می کند، سپس می توانیم بگوییم که هرکس یک کار یا مسئولیت واحد دارد. اغلب اوقات این اتفاق می افتد که وقتی برنامه نویس ها باید ویژگی ها یا رفتار جدیدی را اضافه کنند، همه چیز را در کلاس موجود پیاده می کنند که کاملاً اشتباه است. این کد آنها را طولانی، پیچیده می کند و زمانی که بعداً چیزی نیاز به اصلاح داشته باشد زمان می برد. از لایه ها در برنامه خود استفاده کنید و کلاس های God را به کلاس ها یا ماژول های کوچکتر تقسیم کنید.

  • اصل باز/بسته

این اصل بیان می‌کند که «موجودات نرم‌افزاری (کلاس‌ها، ماژول‌ها، توابع و غیره) باید برای توسعه باز باشند، اما برای اصلاح بسته باشند» به این معنی که شما باید بتوانید یک رفتار کلاس را بدون تغییر آن گسترش دهید. فرض کنید توسعه‌دهنده A باید یک به‌روزرسانی برای یک کتابخانه یا فریم‌ورک منتشر کند و توسعه‌دهنده B می‌خواهد تغییراتی روی آن ایجاد کند یا ویژگی‌هایی را اضافه کند، سپس توسعه‌دهنده B مجاز است کلاس موجود ایجاد شده توسط توسعه‌دهنده A را گسترش دهد، اما توسعه‌دهنده B قرار نیست کلاس را مستقیماً تغییر دهد. . استفاده از این اصل کد موجود را از کد اصلاح شده جدا می کند، بنابراین ثبات، قابلیت نگهداری بهتر را فراهم می کند و تغییرات را مانند کد شما به حداقل می رساند.

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

این اصل توسط باربارا لیسکوف در سال 1987 معرفی شد و طبق این اصل "کلاس های مشتق شده یا فرزند باید جایگزین کلاس های پایه یا والد خود شوند". این اصل تضمین می کند که هر کلاسی که فرزند یک کلاس والد است باید به جای والد خود بدون هیچ رفتار غیرمنتظره ای قابل استفاده باشد. شما می توانید این را به گونه ای درک کنید که پسر کشاورز باید مهارت های کشاورزی را از پدرش به ارث برده و در صورت نیاز بتواند جایگزین پدرش شود. اگر پسر بخواهد کشاورز شود، می تواند پدرش را جایگزین کند، اما اگر بخواهد کریکت باز شود، قطعاً پسر نمی تواند جایگزین پدرش شود، حتی اگر هر دو به یک سلسله مراتب خانواده تعلق دارند. یکی از نمونه های کلاسیک این اصل، مستطیلی است که چهار ضلع دارد. ارتفاع مستطیل می تواند هر مقدار و عرض هر مقدار باشد. مربع مستطیلی با عرض و ارتفاع برابر است. بنابراین می توان گفت که می توانیم ویژگی های کلاس مستطیل را به کلاس مربع گسترش دهیم. برای انجام این کار، باید کلاس فرزند (مربع) را با کلاس والد (مستطیل) تعویض کنید تا با تعریف مربعی که چهار ضلع برابر دارد اما کلاس مشتق شده بر رفتار کلاس والد تأثیری نمی‌گذارد، مطابقت داشته باشد. که اصل جایگزینی لیسکوف را نقض می کند.

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

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

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

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

  • ماژول ها/کلاس های سطح بالا نباید به ماژول ها/کلاس های سطح پایین وابسته باشند. هر دو باید به انتزاعات بستگی داشته باشند.
  • انتزاع ها نباید به جزئیات بستگی داشته باشند. جزئیات باید به انتزاعات بستگی داشته باشد.

خطوط بالا به سادگی بیان می‌کنند که اگر یک ماژول یا کلاس بالا بیشتر به ماژول‌ها یا کلاس‌های سطح پایین وابسته باشد، کد شما کوپلینگ تنگ خواهد داشت و اگر بخواهید در یک کلاس تغییری ایجاد کنید، می‌تواند کلاس دیگری را شکست دهد که خطرناک است. در سطح تولید بنابراین همیشه سعی کنید تا جایی که می توانید کلاس ها را آزادانه همراه کنید و می توانید از طریق انتزاع به این امر برسید. انگیزه اصلی این اصل جدا کردن وابستگی‌ها است، بنابراین اگر کلاس A تغییر کند، کلاس B نیازی به مراقبت یا اطلاع از تغییرات ندارد. می توانید نمونه واقعی باتری کنترل تلویزیون را در نظر بگیرید. کنترل از راه دور شما به باتری نیاز دارد اما به برند باتری بستگی ندارد. شما می توانید از هر مارک XYZ که می خواهید استفاده کنید و کار خواهد کرد. بنابراین می توانیم بگوییم که کنترل از راه دور تلویزیون به راحتی با نام تجاری مرتبط است. وارونگی وابستگی کد شما را قابل استفاده مجدد تر می کند.