מינימליזם בקוד של מתודת הקסם: __init__

רקע:

-שמתי לב, שאם המתודה: __ init __ היא נקייה וברורה - אז בתכלס יכולה לשמש כמו אחלה של אינטרודקציה למחלקה: כלומר: אם קריאה וקולעת מתכנת שמיומן בקריאת קוד בפייתון יכול להציץ בה, וישר לקבל אינפורמציה: גם משמו התכונות של המופעים שהמחלקה עוסקת פה, וגם מהגדרת התכונות - שנותנת מושג מה התכונות הללו מייצגות.

וזה מעלה לי כמה תהיות לגבי כתיבת הקוד של המתודה: __ init __, וגם לגבי תיעוד:

שאלות

1. האם תיעוד זה משהו שמקובל לקרוא על ההתחלה? - או שזה יותר בגדר: “Cheat Sheet”, כדי לקבל עזרה, או חידודים? כמה זה שכיח, שמתכנת פשוט עובר על המחלקה - כדי לקבל את המושג הראשוני שלו?

2. אם סקירה של init כ-“צלילה” למחלקה היא דבר שבשגרה - האם נובע מכך שכדאי שהקוד של המחלקה יהיה כמה שיותר מסודר?

3. אם כן - איך אפשר לשמור על הסדר הזה, כשאנחנו רוצים לעבוד עם תכונות, שההגדרה שלהן מורכבת? (למשל: תנאים - כמו ב-‘חללר’, שם זה לוקח כמה שורות) - מהן הגישות המקובלות לשם כך? הגדרת המאפיין באמצעות קריאה לפונקציה? (שם ייכתבו כל התנאים). אולי לבחוור שלא להגדיר מאפיינים מורכבים מלכתחילה, ולהשאיר את הביטויים שההגדרה שלהם מורכבת למתודות?

1. בד"כ כשבאים להתעסק בחבילות חיצוניות אף אחד לא מזנק לקריאת הקוד. זה לא פרקטי, וככל שהחבילה גדולה יותר זה גם יהיה יותר קשה ויהיו יותר דברים מאתגרים – יש חבילות שכוללות בתוכן מאות מחלקות. תיעוד מכיל הרבה פעמים לא רק את תיעוד המחלקות עצמן, אלא קובצי תיעוד נוספים שנותנים מאיפה להתחיל בכלל. לדוגמה, בחבילה pandas אתה תמצא את 10 minutes to pandas, ובחבילה requests את Quickstart.
2. אתה רוצה שהקוד של המחלקה בכ"מ יהיה כמה שיותר מסודר, בשביל עצמך ובשביל מתכנתים שיגיעו לקוד בעתיד לקריאה/להרחבה.
3. כדי לשמור על ניקיון ב־__init__ מומלץ להוציא בלוקים מורכבים לפונקציות מוגנות ולבצע שם את הלוגיקה. בשבוע הבא נלמד על עוד כלי מעניין.