ماژول‌ها و پایتون – بخش دوّم
توسط: vahit
post qr-code
تو پست قبلی گفتیم که توصیه اکید شده از ساختار import * برای ایمپورت کردن ماژول‌ها استفاده نکنیم، امّا چرا؟ توی این پست چرایی این توصیه رو بررسی می‌کنیم.
مثال پست قبل رو به خاطر بیارید:
برای مثال اگه یه پروژه‌ی تجارت الکترونیک داشته باشیم، نیاز داریم اطلاعاتی رو داخل پایگاه‌داده ذخیره کنیم. ما می‌تونیم تمام کلاس‌ها و توابع مورد نیاز برای ارتباط با پایگاه‌داده رو داخل یک ماژول (که می‌شه حدس زد اسمش database.py خواهد بود) قرار بدیم. بدین ترتیب بقیه‌ی ماژول‌ها (مثل customers, product و …) برای ارتباط با پایگاه‌داده می‌تونن کلاس و تابع مورد نیاز خودشون رو از داخل ماژول پایگاه‌داده ایمپورت (import) کرده و استفاده کنن.
خب اگر من برای ایمپورت کلاس DataBase از دستور زیر استفاده کنم:
|
1 |
from database import DataBase |
۲سال بعد هم که به کد نگاه کنم متوجه می‌شم که کلاس DataBase از کجا اومده حتی اگه ۴۰۰ خط اونورتر خط
|
1 |
db = DataBase |
رو داشته باشم می‌تونم سریع به ابتدای فایل و قسمت ایمپورت‌ها برگردم و ببینم که DataBase چی هست و از کجا اومده. و اگه در مورد DataBase نیاز به راهنمایی داشته باشم می‌تونم فایل ماژول اون رو نگاه بکنم و یا ماژول رو توی مفسر تعاملی (interactive interpreter) ایمپورت و راهنمای (help(database.DataBase)) اون رو ببینم. امّا اگر از ساختار
|
1 |
from database import * |
استفاده می‌کردم خیلی طول می‌کشید که بفهمم کلاس مورد نظرم از کجا اومده و طبیعتاً نگهداری از کد به یک کابوس تبدیل می‌شد!
گذشته از این، با استفاده از این ساختار همه‌ی توابع و کلاس‌های داخل ماژول وارد کد می‌شن و اصولاً دلیلی نداره کلاس یا تابعی که لازم نداریم تو کد باشن و موقع بازبینی کد توسط خودتون یا دیگران توی جواب دادن به سؤال «این کلاس از کجای کره‌ی زمین اومده؟» به مشکل بر می‌خورید.
منبع:
ترجمه‌ی آزاد از صفحه‌ی ۴۴ کتاب Python 3 Object Oriented Programming نوشته‌ی Dusty Phillips
