Designing Method Overloads
כשזה מגיע לעיצוב API עבור ספריות תוכנה, לא פעם נתקלים במצב בו יש לנו
פונקציה שיודעת לקבל מספר לא מבוטל של פרמטרים, אבל בפועל, בד"כ המשתמש לא
מעוניין לפרט מה הוא הערך של כל פרמטר ופרמטר, אלא להשתמש בכל מיני "ערכי
ברירת מחדל" שהפונקציה יודעת לקבל במקום זאת. התופעה הזאת די נפוצה
כשמדובר בפונקציות "פופולריות" שבד"כ נוהגים להשתמש בהם עם סט פרמטרים X,
אבל רק לעיתים נדירות רוצים התנהגות מעט שונה, שמצריכה העברה של מספר
פרמטרים ספציפים נוספים. הבעיה היא, שברגע שאותה פונקציה מקבלת יותר מכמה
פרמטרים בודדים, עומדת בפנינו השאלה "אילו Overloads עלינו להעניק
לפונקציה?". אם למשל אנחנו מקבלים 5 פרמטרים, הרי לא רצוי שנוסיף Overload
חדש עבור כל קומבינציה אפשרית בין הפרמטרים שהמשתמש כן רוצה להעביר, לבין
אלו ערכי ברירת המחדל שהפונקציה יודעת לקבל. אם נעשה זאת, אנחנו יכולים
בקלות להגיע למצב בו אנחנו "מזבלים" את המחלקה שלנו באינספור Overload'ים
שונים ומשונים לאותה הפונקציה.
אז אם כך, כמה Overloads כן צריך לתת? ומה הוא אותו "מספר הקסם" חמקמק? ובכן, בדרך כלל, מספר הקסם הוא 3. לא באמת משנה כמה ואילו פרמטרים הפונקציה שלכם מקבלת, המספר המקסימלי, והבדרך כלל מומלץ של Overloads הוא 3.
מסתבר שכשמסתכלים על אופן השימוש הפופולרי של מפתח ב-API, בדרך כלל אפשר
לראות העדפה ללכת לקצוות. ברוב המקרים הוא יעדיף להשתמש או ב-Overload הכי
מינימלי, שעושה שימוש בכל ערכי ברירת המחדל של הפונקציה, או ב-Overload
הכי מפורט, שנותן לו את השליטה הרבה ביותר על הפרמטרים שמגיעים לפונקציה.
כך שלהתחיל ולעשות מאמצים עילאיים להעניק למפתח כמה שיותר אפשרויות לבחור
מתוכן, בסופו של דבר מתבררת כמוטעת, ובסוף של דבר כל "הרעש" הזה
שה-Overloads גורמים לו, רק מבלבל את המפתח וגורמים ל-API להראות מסובך
שלא לצורך.
מכאן בדיוק מגיע מספר הקסם. בצד האחד של הסקאלה, אנחנו צריכים מעוניינים
לחשוף את הפונקציה הבסיסית, והפשוטה ביותר. מצד שני, אנחנו צריכים להעניק
כמה שיותר שליטה למפתח, כך שנחשוף לו Overload נוסף בו הוא יוכל לפרט
ולבחור כל פרמטר שהוא מעוניין להעביר. ה-Overload השלישי והנוסף הוא יותר
עניין של Sweet Spot שאפשר למצוא. לכאן צריך להכניס מעט היגיון ומחשבה,
ולמצוא האם קיים איזשהו Overload ביניים, שנותן איזשהוא ערך מוסף למפתח.
איזשהו Overload בעל פוטנציאל פופולריות ונוחות עבור המפתח. במידה והפעלתם
את שיקול דעתכם ולא ראיתם לנכון להוסיף Overload כזה, כמובן שתמיד אפשר גם
לוותר עליו.
כי כמו תמיד, Less is Better.