برداشتی از کتاب Architecture Patterns with Python - مقدمه

طرح از فتانه کهن‌زاده
طرح از فتانه کهن‌زاده

در راستای این مقاله، می‌توانید مقالات زیر را هم مشاهده کنید:

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

کتاب Architecture Patterns with Python از جمله کتاب‌هایی است که پیرامون بحث طراحی نرم‌افزار صحبت می‌کند. این کتاب از زبان پایتون برای بیان مطالب خود استفاده می‌کند، تا بتواند به راحتی مباحث مربوط به طراحی نرم‌افزار را بیان کند.

کتاب پیرامون سه محور یا معماری برای توسعه نرم‌افزار صحبت می‌کند:

  • توسعه تست محور یا Test-driven development (TDD)
  • طراحی دامنه محور یا Domain-driven design (DDD)
  • میکروسرویس‌های واکنش‌گرا یا Reactive microservices

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

زمانی که کلمه بی‌نظمی (chaos) را می‌شنوید چه چیزی به ذهن شما خطور می‌کند؟ اگر با کلمه نظم (order) مواجه شوید، تداعی‌گر چه چیزی برای شما است؟ برای مثال یک باغچه می‌تواند منظم باشد، اگر علف‌های هرز آن چیده شده باشد، یا کنار باغچه فنس‌کشی باشد و هر کدام از سبزیجات در یک دسته جدا کاشته شده باشند. اما اگر به باغچه رسیدگی نشود، آن باغچه تبدیل به یک باغچه نامنظم می‌شود که پر از علف هرز است و به گیاهان آن رسیدگی نشده است.

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

اما خوشبختانه تکنیک‌هایی وجود دارد تا از این مسئله جلوگیری شود.

تکنیک Encapsulation and Abstractions

اصطلاح encapsulation یعنی ساده‌سازی یک رفتار و پنهان کردن داده‌ها. در ابتدا با شناسایی وظیفه‌ای که در کد ما وجود دارد، آن رفتار را شناسایی می‌کنیم. سپس این وظیفه را به یک شئ یا تابع خوش تعریف می‌دهیم. به این کار encapsulation می‌گوییم و آن شئ یا تابع را abstraction می‌نامیم.

به دو کد زیر توجه کنید:

https://gist.github.com/2e21faa21bf336147b44265d5650cd7b.git
https://gist.github.com/eaac818f22f4ee30ac804a0ac83939af.git

هر دو کد کار یکسانی را انجام می‌دهند. هر دو مقادیر یک فرم را می‌گیرند و آن را به یک url ارسال می‌کنند تا از موتور جستجوی API استفاده کند. اما کد دوم خواناتر و قابل فهم‌تر است، زیرا از سطح بالاتری از abstraction استفاده کرده است.

می‌توان گفت که encapsulation و abstraction ابزار قدرتمندی است که باعث می‌شود کد ما خواناتر، تست پذیرتر و نگهداری آن آسان‌تر باشد.

لایه‌بندی

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

معماری سه‌لایه‌ای
معماری سه‌لایه‌ای

در معماری لایه‌ای برنامه به دسته‌های جدا از هم تبدیل می‌شود. سپس مشخص می‌شود که هر دسته کدام دسته را می‌تواند فراخوانی کند. معماری سه‌لایه‌ای یکی از معروف‌ترین آنها است. لایه presentation همان رابط کاربری است. رابط کاربری می‌تواند یک صفحه وب، API و یا یک command line باشد. این لایه با لایه منطقی business ارتباط دارد. لایه business نقش‌های فرایندی و workflow را به عهده دارد. در نهایت هم لایه database است که وظیفه ذخیره و ارسال داده‌ها را دارد.

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