بخش سوم Clean Architecture - مقدمه

نرم‌افزارهای خوب با کد‌های تمیز شروع می‌شوند. اگر آجر‌هایی که برای ساخت یک ساختمان استفاده می‌کنیم خوب نباشند، معماری ساختمان اهمیت چندانی ندارد. در طرف مقابل با آجر‌های بسیار خوب هم امکان ساخت به هم‌ریختگی مطلق وجود دارد. این جایی است که SOLID وارد می‌شود.اصول SOLID به ما می‌گویند که چکونه توابع و داده‌ها را داخل کلاس‌ها کنار هم قرار دهیم و کلاس‌ها چگونه باید کنار هم قرار بگیرند. وقتی از واژه کلاس استفاده می‌کنیم نباید تصور کنید که این اصول صرفا برای OOP کاربرد دارند. منظور ما از کلاس در این اصول صرفا مجموعه‌ای از داده‌ها و توابع است که کنار هم قرار گرفته اند. هر نرم‌افزاری قطعا همچین مجموعه‌ای از داده‌ها و توابع را خواهد داشت، حال فرقی نمی‌کند که اسم این مجموعه کلاس باشد یا نه! این اصول مخصوص این گروه از توابع و داده‌ها است.هدف اصول SOLID ایجاد ساختار نرم افزاری سطح متوسطی است که:قابل تغییر باشدبه سادگی قابل فهم باشدپایه‌ای برای اجزایی باشد که در بسیاری از نرم افزار‌ها قابل استفاده است.واژه سطح متوسط به این حقیقت اشاره دارد که این اصول توسط برنامه نویسانی که در سطح ماژول‌ها کار می‌کنند مورد استفاده قرار می‌گیرد. آن‌ها بالاتر از سطح کد مورد استفاده قرار می‌گیرند، و برای تعریف ساختار نرم افزارها در سطح ماژول‌ها و کامپوننت‌ها به ما کمک می‌کنند.همانطور که با استفاده از آجر‌های با کیفیت ایجاد معماری بد امکان پذیر است،پس ممکن است با استفاده از کامپوننت‌های خوب هم یک آشفتگی کامل در نرم‌افزار ایجاد کرد. پس بعد از اینکه با اصول SOLID آشنا شدیم به سراغ سطح بالا‌تر می‌رویم و همتایان این اصول را در سطح ماژول‌ها و کامپوننت‌ها بررسی می‌کنیم و اصولی را در سطح معماری سطح بالا بررسی می‌کنیم.تاریخچه SOLID بسیار قدیمی است. در حقیقت هنگامی که در دهه 1980 با همکاران خود در USENET ( فرض کنید فیس‌بوک در دهه 80 میلادی) در مورد اصول طراحی بحث می‌کردم این اصول را کنار هم قرار دادم. در صول سال‌ها این اصول ارتقا و تغییر پیدا کرده است. بعضی ها حذف شدند، تعدادی با هم ترکیب شدند و برخی هم به این مجموعه اضافه شدند. مجموعه SOLID در اوایل قرن 2000 به دنیا آمد. البته من آن‌ها را با ترتیب دیگری ارائه داده بودم.در سال 2004 یا همان حوالی مایکل فِدِرز ایمیلی برای من ارسال کرد و گفت اگر من این اصول را به شکل دیگری مرتب کنم سرنام آن‌ها SOLID می‌شود و اینگونه بود که SOLID پا به عرصه وجود گذاشت.طی 5 فصل آتی با جزئیات هریک از این اصول آشنا خواهیم شد. اما اینجا شرح کوتاهی از هر‌کدارم را ارائه خواهم کرد.اصل مسئولیت یکتا یا SRP:این قانون یک نتیجه گیری فعال از قانون کانوی است. بهترین ساختار یک سیستم نرم‌افزاری از ساختار سازمانی که از آن استفاده می‌کنید، تاثیر می‌گیرد. پس بهتر است هر ما ماژولی یک و تنهای یک دلیل برای تغییر داشته باشد.باز برای توسعه بسته برا تغییر یا OCP:برتراند مِیِر در دهه‌ی 1980 این اصل را به شهرت رسانید. مخلص کلام اینکه هر سیستم نرم‌افزاری باید به سادگی قابل تغییر باشد. نرم‌افزارها باید به گونه‌ای طراحی شوند که عملکرد‌ آن‌ها با اضافه کردن کد‌های جدید عوض شود نه با عوض کردن کد‌های موجود.Bertrand Meyerآقای اصل جانشینی لیسکو یا LSP:در سال 1988 این قانون توسط خانم باربارا لیسکو به دنیا معرفی شد. این اصل می گوید برای ساختن سیستم‌های نرم افزاری از اجزای قابل تعویض، این اجزا باید به قراردادی پایبند باشند که این قرارداد جایگزینی آن‌ها را ممکن سازد. بانو Barbara Liskov اصل تفکیک روابط یا ISP:این اصل به طراحان نرم‌افزار می‌گوید سیستم را طوری طراحی کنند که بخش‌های مختلف به چیز‌هایی که استفاده می‌کنند وابسته نباشند.اصل معکوس سازی وابستگی یا DIP:کد‌هایی که خط مشی سطح بالا را تعیین می‌کنند نباید به کدهایی که جزئیات سطح پایین را پیاده سازی می‌کنند وابسته باشند. بهتر است که جزئیات سطح پایین به خط مشی‌ها وابسته باشند.این اصول با جزئیات کامل در نشریات مختلفی در طی این سال‌ها منتشر شده است. در طی فصل‌های آتی به جای تکرار حرف‌های گذشته جزئیات گفته شده در سایر مطالب به کاربرد این اصول در سطح معماری نرم‌افزار می‌پردازیم. اگر با این اصول آشنایی کامل ندارید، در مطالبی که در ادامه بیان می‌شود به طور دقیق با این جزئیات آشنا نخواهید شد، پس پیشنهاد می‌کنم پیش از مطالعه فصل‌های آتی، با این اصول در یکی از منابعی که با جزئیات توضیح داده شده اند آشنا شوید. پ.ن: از اونجایی که دونستن این اصول قبل از مطالعه ادامه مطالعه این فصل‌ها ضروری‌تر از ضروری هست، 5 فصل آینده هر کدام به 2 قسمت تقسیم می شن، در قسمت پیش نیاز اصلی که قرار هست در اون فصل صحبت بشه کامل بررسی می‌شه و قسمت بعد اون فصل مطابق با سرفصل کتاب ارائه خواهد شد.