درک اصول SOLID

اصول SOLID پنج دستورالعمل طراحی شی گرا هستند که به توسعه دهندگان کمک می کند تا سیستم هایی را ایجاد کنند که برای حفظ، گسترش و آزمایش آسان تر هستند.آنها توسط رابرت سی مارتین در اوایل دهه ۲۰۰۰ معرفی شدند و از آن زمان به عنوان سنگ بنای معماری نرم افزار مدرن تبدیل شده اند.

  • اصل مسئولیت (SRP): یک کلاس باید تنها یک دلیل برای تغییر داشته باشد، به این معنی که باید مسئول یک عملکرد واحد باشد.
  • باز / اصل از دست رفته (OCP): کلاس باید برای تمدید باز باشد، اما برای اصلاح بسته است - شما می توانید رفتارهای جدید بدون تغییر کد موجود اضافه کنید.
  • اصل اساسی جایگزین (LSP): زیرنوع ها باید برای انواع پایه خود بدون شکستن سیستم جایگزین شوند.
  • اصل Segregation (ISP): مشتریان نباید مجبور به وابسته به رابط هایی شوند که استفاده نمی کنند؛ بهتر است رابط های کوچک و خاص زیادی نسبت به یک رابط کاربری بزرگ و عمومی داشته باشند.
  • [FLT: 1] اصل عدم پرداخت (DIP): ماژول های سطح بالا نباید به ماژول های سطح پایین وابسته باشند؛ هر دو باید به Abstractions وابسته باشند - جزئیات باید به Abstraction ها وابسته باشند.

نقش UML در تجسم معماری نرم افزار

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

UML شامل 14 نوع نمودار است، اما مناسب ترین برای تجسم SOLID نمودار کلاس، نمودارهای جزء، نمودارها و نمودارهای بسته بندی است.هر نوع نمودار می تواند جنبه های مختلف از اصول را تأکید کند - به عنوان مثال، نمودارهای کلاس نشان می دهد مسئولیت ها و رابط ها، در حالی که نمودارهای جزء دستورالعمل های وابستگی و نقاط بیرونی را برجسته می کنند.

نقشه برداری UML Diagrams به هر اصل SOLID

اصل مسئولیت تک و دیگرام های کلاس

نمودار کلاس ایده آل برای تأیید انطباق SRP است. نمودار کلاس به خوبی طراحی شده نشان می دهد هر کلاس با مجموعه ای روشن و متمرکز از ویژگی ها و روش ها.اگر یک کلاس دارای مسئولیت های متعدد، جعبه آن در نمودار شامل عملیات های غیر مرتبط - پرچم قرمز برای نقض SRP.

به عنوان مثال، یک کلاس به نام "InvoiceManager" که هر دو محاسبه فاکتور و ارسال ایمیل را کنترل می کند، SRP را نقض می کند. نمودار کلاس روش هایی مانند "calculateTotal() و "ارسال ایمیل" را در داخل همان جعبه نشان می دهد، و نشان می دهد که نیاز به تقسیم کلاس به "Invoicealcculator" و "Emailservice" را به تیم های نقض بصری کمک می کند.

Open/Closed Principles

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

در یک نمودار جزء، شما می توانید این را با استفاده از رابط های ارائه شده و مورد نیاز نشان دهید.یک جزء “PaymentProcessor”، به عنوان اجزای جداگانه ای که این رابط را پیاده سازی می کنند، اضافه می شود. نمودار روشن می کند که پردازنده اصلی نیازی به تغییر ندارد – تنها به انتزاع بستگی دارد.

اصل اساسی و وراثت

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

نقض کلاسیک LSP یک طبقه 'Square' است که از 'Rectangle' در نمودار به ارث می برد، اگر تغییرات 'setWidth()' را تغییر دهد تا همچنین ارتفاع را تنظیم کند، آن را تجزیه "قرارداد "Rectangle" را می شکند. نمودار باید نشان دهد که "Square' واقعا جایگزین نیست - پس از آن ممکن است به طور مستقیم با استفاده از "SShape" ".

رابط Segregation Principles و Interface Diagrams

UML می تواند رابط های کاربری را به طور صریح با استفاده از جعبه های رابط (با < کلیشه ای (IP) مدل سازی کند) برای اجرای ISP، شما رابط های چندگانه کوچک را به جای یک رابط بزرگ ایجاد می کنید. نمودار نشان می دهد که کدام کلاس ها به کدام رابط ها وابسته هستند؛ اگر یک کلاس روش های استفاده نشده در یک رابط کاربری داشته باشد، این یک نقض است.

به عنوان مثال، به جای رابط کاربری چندFunctionPrinter با \"print()، \"can()، \"fax()، شما به "Printable" تقسیم می کنید، \"Scannable " و \"Faxable'''''، نمودار کلاس نشان می دهد که یک \"BasicPrinter' تنها مشتریان را پیاده سازی می کند، در حالی که همه عملیات های غیر قابل اعتماد هستند و به این روش های وابسته هستند.

اصل عدم وابستگی و وابستگی به دیگرام

هر دو نمودار کلاس و نمودار بسته می توانند انطباق را نشان دهند. DIP بیان می کند که ماژول های سطح بالا (به عنوان مثال، منطق کسب و کار) نباید به ماژول های سطح پایین (به عنوان مثال، رانندگان پایگاه داده) وابسته باشند.

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

بهترین روش ها برای ایجاد دیگرام UML برای معماری SOLID

این دستورالعمل ها را برای تولید نمودارهای پاک و آموزنده UML که اصول SOLID را تقویت می کنند دنبال کنید:

  • از کلیشه ها و یادداشت ها استفاده کنید: < < استفاده کنید، و [< کلیشه ها را برای توضیح تصمیمات طراحی اضافه کنید، مانند اینکه چرا یک کلاس فقط یک مسئولیت دارد.
  • نمودارها را متمرکز کنید: یک نمودار باید یک اصل یا مجموعه کوچکی از اصول مرتبط را مورد توجه قرار دهد.
  • تنها روابط مرتبط را در نظر بگیرید؛ [FLT 1] ارث، ارتباط، تجمع و فلش های وابستگی را نشان دهید که در آن مهم هستند.
  • نقض نور بالا: از رنگ های مختلف یا خطوط تیره برای علامت گذاری روابط مشکل ساز استفاده کنید، به عنوان مثال، یک فلش وابستگی قرمز از سطح بالا به کد سطح پایین می تواند نقض DIP را نشان دهد.
  • با بازسازی: به عنوان شما دوباره طراحی را برای دیدار با SOLID، به روز رسانی نمودارها.UML یک مصنوعات زنده است - آن را به عنوان یک همراه به کد، نه یک طرح یک بار.

قرص های معمول و چگونگی اجتناب از آن

حتی توسعه دهندگان با تجربه می توانند در هنگام استفاده از UML برای طراحی معماری های SOLID به دام بیفتند و در اینجا اشتباهات و راه های مکرری برای کنار گذاشتن آنها وجود دارد:

  • به طور خلاصه جذب زود: شروع با رابط های بیش از حد و یا کلاس می تواند نقض YANI (شما Gonna Need It) با یک نمودار کلاس ساده شروع، سپس اضافه کردن انتزاع تنها زمانی که مورد نیاز توسط اصول SOLID - معمولا در طول بازسازی.
  • عدم استفاده از سیم کشی UML [FLT1] [FLT1]، سوء استفاده از انواع فلش (به عنوان مثال، با استفاده از یک فلش عمومی سازی که در آن یک فلش وابستگی درست است) می تواند به تفسیر نادرست UML 2.5 اصول اولیه برای جلوگیری از ابهام اشاره کند.
  • تشخیص LSP در نمودارهای توالی: نمودارهای توالی تعاملات زمان اجرا را نشان می دهد.اگر یک شی زیر کلاس جایگزین یک شی کلاس پایه و رفتار تغییرات تعامل به طور غیر منتظره، LSP شکسته می شود.
  • جهت وابستگی به هم افزایی: DIP در مورد جهت وابستگی است.در نمودار بسته همیشه فلش از مشتری به سرور را ترسیم کنید اگر چرخه ها یا فلش هایی را که به روش اشتباه اشاره می کنند، انتزاع را دوباره فعال کنید.
  • نمودارهای ماینگ بسیار دقیق هستند: یک نمودار کلاس نشان می دهد که هر یک از آنها را به هم ریخته و بر روی رابط های عمومی و روابط کلیدی که اصول SOLID را اجرا می کنند، تمرکز می کند.

ابزارهایی برای ایجاد دیگرام UML

چندین ابزار می تواند به شما در ایجاد نمودارهای UML کمک کند که با کد همگام شوند.یکی را انتخاب کنید که متناسب با جریان کار شما باشد:

  • برنامه ریزی شده است: یک ابزار نمودار مبتنی بر متن که با کنترل نسخه ادغام می شود، توصیف متن ساده را بنویسید و نمودارها را به طور خودکار برای تیم هایی که می خواهند نمودار به عنوان کد. بیشتر در PlantUML
  • Draw.io (diagrams.net): ویرایشگر نمودار آنلاین رایگان، پشتیبانی از UML stencils و صادرات آسان است.
  • لوکیداکت: یک پلت فرم پرداخت شده با قالب UML و همکاری زمان واقعی، ادغام با Confluence و Jira را ارائه می دهد.
  • مدلیو: یک ابزار مدل سازی منبع باز که از UML و BPMN پشتیبانی می کند می تواند کد را از نمودارهای کلاس و کد موجود در موتور معکوس تولید کند.
  • IntelliJ IDEA Ultimate: شامل ویژگی های نمودارسازی داخلی برای کلاس، بسته و نمودار وابستگی به طور مستقیم با کد پایه خود برای هماهنگ سازی زنده کار می کند.

برای درک عمیق تر از اصول SOLID و ادغام UML، می توانید به نوشتن اصلی رابرت C. مارتین در اصول OOD (PDF و مقاله ویکی پدیا در مورد SOLID اصول اشاره کنید.

نتیجه گیری

نمودار UML اصول انتزاعی SOLID را به مدل های بصری بتنی تبدیل می کند که توسعه دهندگان می توانند بررسی، بحث و بهبود کنند. با نقشه برداری هر اصل به نوع نمودار مناسب - نمودارهای کلاس برای SRP و ISP، نمودارهای جزء برای OCP و DIP، و سلسله مراتب ارثی برای LSP - شما می توانید به طور سیستماتیک تأیید کنید که معماری شما انعطاف پذیر، حفظ و مقیاس پذیر است.

کلید این است که از UML نه به عنوان یک اثر هنری بروکراتیک بلکه به عنوان یک ابزار زنده که با کد شما تکامل می یابد، همراه با نسل خودکار نمودار و بررسی منظم کد، UML تبدیل به یک متحد قدرتمند در ساخت سیستم های سازگار با SOLID است که آزمون زمان ایستاده است.