منبع اصلی نوشتار زیر در این لینک قرار دارد

ماژول‌ها و پایتون – بخش دوّم

python modules

post qr-code

تو پست قبلی گفتیم که توصیه اکید شده از ساختار‪ import * ‬برای ایمپورت کردن ماژول‌ها استفاده نکنیم، امّا چرا؟ توی این پست چرایی این توصیه رو بررسی می‌کنیم.

مثال پست قبل رو به خاطر بیارید:

برای مثال اگه یه پروژه‌ی تجارت الکترونیک داشته باشیم، نیاز داریم اطلاعاتی رو داخل پایگاه‌داده ذخیره کنیم. ما می‌تونیم تمام کلاس‌ها و توابع مورد نیاز برای ارتباط با پایگاه‌داده رو داخل یک ماژول (که می‌شه حدس زد اسمش database.py خواهد بود) قرار بدیم. بدین ترتیب بقیه‌ی ماژول‌ها (مثل customers, product و …) برای ارتباط با پایگاه‌داده می‌تونن کلاس‌ و تابع مورد نیاز خودشون رو از داخل ماژول پایگاه‌داده ایمپورت (import) کرده و استفاده کنن.

خب اگر من برای ایمپورت کلاس DataBase از دستور زیر استفاده کنم:

from database import DataBase

۲سال بعد هم که به کد نگاه کنم متوجه می‌شم که کلاس DataBase از کجا اومده حتی اگه ۴۰۰ خط اونورتر خط

db = DataBase

رو داشته باشم می‌تونم سریع به ابتدای فایل و قسمت ایمپورت‌ها برگردم و ببینم که DataBase چی هست و از کجا اومده. و اگه در مورد DataBase نیاز به راهنمایی داشته باشم می‌تونم فایل ماژول اون رو نگاه بکنم و یا ماژول رو توی مفسر تعاملی (interactive interpreter) ایمپورت و راهنمای ‪(help(database.DataBase))‬ اون رو ببینم. امّا اگر از ساختار

from database import *

استفاده می‌کردم خیلی طول می‌کشید که بفهمم کلاس مورد نظرم از کجا اومده و طبیعتاً نگهداری از کد به یک کابوس تبدیل می‌شد!

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

منبع:

ترجمه‌ی آزاد از صفحه‌ی ۴۴ کتاب Python 3 Object Oriented Programming نوشته‌ی Dusty Phillips



برچسب ها : , , , , , , ,