برنامه نویسی ماژولار چیست؟ با مثال و راهنمای نوشتن ماژول خوب

هدف فقط این نیست که تعداد فایل‌ها را زیاد کنیم. هدف این است که کد را طوری تقسیم کنیم که هر بخش مسئولیت مشخصی داشته باشد و ارتباط بین بخش‌ها به‌صورت منطقی و کنترل‌شده باشد.

مزیت‌های مختلفی را می‌توان برای برنامه‌نویسی ماژولار در نظر گرفت. اما اگر بخواهم بگویم که مهم‌ترین مزیت برنامه‌نویسی ماژولار چیست؟ پاسخ می‌دهم که با تقسیم منطقیِ کدها، کار با پروژه در طولانی‌مدت و نگهداری و توسعه آن را ساده‌تر کنیم.

در ادامهٔ این بخش چهار مورد از شناخته‌شده‌ترین مزیت‌ها را تحلیل می‌کنیم. در صورت تمایل می‌توانید لیست بلندتری از مزیت‌هایش را در این مقاله انگلیسی (+) بخوانید.

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

برای مثال، اگر دنبال منطق پرداخت و کدهای مربوط به آن باشیم، انتظار داریم که کد آن را در بخش payments پیدا کنیم. بنابراین نیاز نیست در بین هزاران خط کدِ پروژه، دنبالش بگردیم.

فرض کنید روش محاسبهٔ هزینه ارسال تغییر کرده است. اگر منطق ارسال در یک ماژول (فایل یا فولدر) مشخص قرار داشته باشد، معمولاً کافی است همان بخش را تغییر دهیم؛ بدون اینکه لازم باشد کل برنامه را مرور کنیم.

هر چه یک بخش کوچک‌تر و مسئولیت آن مشخص‌تر باشد، ارزیابی رفتار و کدهای آن راحت‌تر می‌شود.

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

طراحی ماژولار و جدا کردن اجزای سیستم نیز از روش‌های رایج برای ساده‌تر شدن تست (Testing) و دیباگ (Debugging) است.

اگر یک ماژول را طراحی کنیم، ممکن است بتوانیم همان کد را در چند قسمت همین پروژه یا حتی پروژه‌های دیگر نیز استفاده کنیم.

برای مثال، فرض کنید من ماژولی برای ارجاع کاربر به درگاه پرداخت بانک و تأیید پرداخت نوشته‌ام. از این ماژول می‌توانم در هر پروژهٔ دیگری که نیاز به درگاه پرداخت دارد استفاده کنم. بنابراین سرعت توسعه من نیز بیشتر شدن می‌یابد.

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

فرض کنیم فایلی به‌نام calculator.py داریم که در آن دو تابع برای جمع و ضرب دو عدد نوشته‌ایم.

# calculator.py

def add(a, b):
 return a + b

def multiply(a, b):
 return a * b

این یک ماژول است. اسمش را می‌گذارم ماژول محاسبه‌گر (calculator). حالا در فایل اصلی پروژه (مثلاً app.py) می‌توانیم این ماژول را وارد کرده و از توابع آن استفاده کنیم:

# app.py

from calculator import add, multiply

print(add(10, 5))
print(multiply(10, 5))

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

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

بنابراین حتی در همین مثال ساده نیز، برنامه ما به‌جای اینکه تمام منطق محاسبات را در فایل اصلی داشته باشد، مسئولیت‌ها جدا شده است.

این‌گونه، اگر زمانی محاسبه جمع اشتباه انجام شود، می‌دانیم باید سراغ فایل calculator.py برویم. واضح است که تابع add() صرفاً یک مثال است. در پروژه‌های واقعی، چنین توابعی می‌توانند محاسبات پیچیده و مختلفی انجام دهند.

یک نکته مهم را همین ابتدا بگویم: «ماژولار کردن الزاماً به‌معنی تقسیم کد بین چند تا فایل نیست.»

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

پس بهتر است هنگام طراحی ماژول‌ها، نکات طراحی ماژول خوب را در نظر بگیریم. در این بخش چهار نکتهٔ کاربردی را مطرح می‌کنم.

ساختار زیر را در نظر بگیرید:

# چندین تابع با اهداف مختلف در یک فایل

utils.py
├── ارسال ایمیل
├── محاسبه مالیات
├── اتصال دیتابیس
├── تغییر سایز و حجم عکس
└── مدیریت کاربر

مشکل این‌جاست که utils.py تقریباً همه کاری انجام می‌دهد! بهتر است مسئولیت‌ها را منطقی‌تر جدا کنیم. برای مثال، بهتر است ساختاری شبیه ساختار زیر داشته باشیم که در آن هر فایل مسئولیت مشخصی دارد:

# چند فایل در یک فولدر

utils/
├── email.py
├── tax.py
├── database.py
├── image.py
└── user.py

البته این تقسیم‌بندی یک قانون خشک و ثابت نیست. در پروژه‌های واقعی بهتر است اندازه و ارتباط هر بخش را نیز در نظر بگیریم.

به‌زبان ساده‌تر:

هر ماژول باید هدف روشن و تا حدِ قابلیت واحد داشته باشد.

این طرز فکر با مفاهیمی مانند اصل مسئولیت واحد (Single Responsibility) و جداسازی دغدغه‌ها (Separation of Concerns) نیز هم‌راستا است؛ یعنی مسئولیت‌های مختلف را تا حد فرصت از یکدیگر جدا کنیم.

فرض کنید تغییر یک خط در payment.py باعث شود مجبور شویم که ۱۰ فایل دیگر را نیز تغییر دهیم. احتمالاً وابستگی بین این بخش‌ها/ماژول‌ها زیاد شده است.

هدف در طراحی ماژول رسیدن به وابستگی کمتر (اصطلاحاً Loose Coupling) است. یعنی هر ماژول تا حد ممکن درگیر شرح داخلی ماژول‌های دیگر نباشد و از طریق یک رابط مشخص با آن‌ها ارتباط برقرار کند.

در مثال شرکت در دنیای واقعی، کارشناس ارائه لازم نیست که بداند محاسبات مالی قرارداد و تفکیک مالیات‌ها دقیقاً چگونه انجام می‌شود. ایشان گزارش‌ها محصول و مشتری را در قالب مشخصی به حسابداری می‌دهد و در نهایت پیش‌فاکتور را دریافت می‌کند.

در برنامه‌نویسی نیز بهتر است ماژول‌ها بیشتر با «کاری که هر ماژول انجام می‌دهد» در ارتباط باشند و نه با شرح نحوه انجام آن کار.

در یک نگاهِ خیلی ساده، کارشناس فروش‌رسانی را استفاده‌کننده یک ماژول در نظر بگیرید. (فایلی که تابع/کدهای ماژول دیگر را صدا می‌زند.) داده‌ها مشتری و محصول به‌عنوان آرگومان‌های ورودی تابع به ماژول (حسابداری) داده می‌شود. در نهایت خروجی (پیش‌فاکتور) به‌عنوان برآیند بازمی‌گردد. (retu می‌شود.)

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

user.py
├── create_user()
├── update_user()
└── delete_user()

این ساختار معمولاً بهتر از حالتی است که توابع مرتبط با کاربر را در پنج فایل جداگانه و پراکنده قرار دهیم.

این‌جا مفهوم High Cohesion اهمیت پیدا می‌کند؛ یعنی کدهای یک ماژول تا حد ممکن به یکدیگر مرتبط باشند.

یک ماژول خوب تمام شرح داخلی و نحوه پردازشش را به بخش‌های دیگر نشان نمی‌دهد. در ادامه نباید سایر ماژول‌ها را به اطلاعات درونی خودش وابسته کند.

برای درک بهتر، فرض کنید که ماژول ایمیل تابع send_email(user, message) را در اختیار ما می‌گذارد. این‌گونه می‌توانیم در هر جایی، پیامی را به کاربر موردنظر ایمیل کنیم.

بخش‌های دیگر برنامه که می‌خواهند این تابع را صدا بزنند، لازم نیست بدانند داخل این تابع چه اتفاقاتی رخ می‌دهد. مثلاً:

ماژول ایمیل باید یک رابط ساده در اختیار برنامه قرار دهد و فقط خودش مسئول اطلاعات داخلی‌اش باشد.

در دنیای واقعی نیز، کارشناس ارائه فقط مشخصات قرارداد را به حسابداری می‌دهد. برای او فرقی ندارد که محاسبات حسابداری با نرم‌افزار انجام می‌شود یا به‌صورت دستی؛ چیزی که مهم است این است که ورودی مشخصی بدهد و انتظار یک خروجی مشخص داشته باشد.

این ایده با مفاهیمی مثل انتزاع در برنامه‌نویسی (Abstraction) و پنهان‌سازی گزارش‌ها (Information Hiding) ارتباط دارد.

تمام این اصول در برنامه‌نویسی ماژولار کمک می‌کنند که کد ما ساختارمندتر باشد، وابستگی بخش‌ها کمتر شود و تغییر دادن پروژه راحت‌تر باشد.

مثلاً برای تغییر روش ارسال ایمیل، صرفاً کافی است که پیاده‌سازی بدنهٔ تابع send_email() را تغییر دهیم؛ اما سایر بخش‌های برنامه همچنان همان تابع را صدا می‌زنند بدون اینکه نیاز باشد آن‌ها را تغییر دهیم.

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

اما خوب است که یک نکته مهم را دوباره تأکید کنم: «ماژولار کردن پروژه صرفاً به‌معنی چند فایلی کردن آن نیست!»

برای مثال، ساختار زیر را در نظر بگیرید:

user.py # کاربر
payment.py # پرداخت
order.py # سفارش
report.py # گزارش
email.py # ایمیل

اگر تغییر در payment.py مجبورمان کند که چهار فایل دیگر را نیز دستکاری کنیم، ما فقط فایل‌ها را جدا کرده‌ایم و هنوز طراحی ماژولار خوبی نداریم.

ماژولار بودن عمدتاً به نحوهٔ تقسیم مسئولیت‌ها، میزان وابستگی و نوع ارتباط بخش‌های مختلف مرتبط می‌شود و نه تعداد فایل‌های پروژه.

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

نه لزوماً. ماژول یک مفهوم طراحی و سازمان‌دهی کد است و نحوه پیاده‌سازی آن به زبان و معماری پروژه بستگی دارد. مثلاً در پایتون، یک فایل .py می‌تواند یک ماژول باشد و در ماژول‌های دیگر import شود؛ اما در زبان PHP معمولاً مجموعه‌ای از فایل‌ها را معادل یک ماژول در نظر می‌گیرند.

خیر! اگر یک برنامه ۳۰ خطی داریم، تقسیم آن به ۱۰ فایل مختلف احتمالاً فقط پیچیدگی ایجاد می‌کند. ماژولار کردن زمانی ارزش بیشتری پیدا می‌کند که برنامه در مقیاس نسبتاً متوسط یا بزرگ باشد و چندین مسئولیت مختلف داشته باشد. بنابراین این تصویر که «هر چه تعداد فایل‌ها بیشتر باشد، کدهای پروژه بهتر هستند» صحیح نیست.

خیر! این دو مفهوم با یکدیگر متفاوت هستند اما می‌توانند در یک پروژه کنار هم استفاده شوند. برنامه‌نویسی شیءگرا بیشتر بر کلاس‌ها، اشیاء و نحوه سازمان‌دهی رفتار و داده تمرکز دارد، در حالی که برنامه‌نویسی ماژولار بر تقسیم منطقی سیستم، مدیریت مسئولیت و وابستگی بین بخش‌های آن تأکید می‌کند.

این آموزش برای همیشه مجانیه! می‌تونید با اشتراک‌گذاری لینک این صفحه از ما حمایت کنید یا با تهیه یه فنجون نوشیدنی بهمون انرژی بدید!

سوالات متداول

چرا برنامه‌نویسی ماژولار چیست؟ با مثال و راهنمای نوشتن ماژول خوب اهمیت دارد؟

این موضوع به دلیل اطلاعات و کاربردهای مرتبط، مورد توجه کاربران قرار گرفته است.

مهم‌ترین نکات درباره ماژولار چیست؟

جزئیات مهم و نکات قابل توجه درباره ماژولار در متن مقاله بررسی شده است.

برنامه‌نویسی ماژولار چیست؟ با مثال و راهنمای نوشتن ماژول خوب چیست؟

در این مطلب اطلاعات، جزئیات و نکات مرتبط با برنامه‌نویسی ماژولار چیست؟ با مثال و راهنمای نوشتن ماژول خوب بررسی شده است.