תכנון פונקציה: האם לשים פרמטרים מרובים או מערך

[mekev]

שפות: c# / js

אשמח לשמוע מניסיונך
כאשר הינך בונה פונקציה שאמורה לקבל 20 פרמטרים (דוגמא: מפרט עבודה לצורך תמחור)

מה השיקול שלך לעשות לפונקציה האם 'פרמטרים מרובים', או מערך

• ביצועים
• תחזוקה ותפעול

[OdedDvir]

לא זה ולא זה.
הדרך הנכונה היא ליצור אובייקט שמכיל את כל השדות ולהעביר אותו לפונקציה.
כך C#:

public record JobSpecifications {
   public string JobName {get; set;}
   public double WorkHours {get; set;}
   ...
}

public decimal CalculatePrice(JobSpecifications specs)
{
   ...
   return price;
}

זה יעיל מכל הבחינות, והרבה יותר קל לתחזוקה.

[dovid]

השאלה וגם התשובה מדברים על תכנות רגיל, לא OOP.
בOOP בד"כ הפרמטרים מרכיבים מחלקות שמייצגות את הישויות השונות, והפונקציה היא בד"כ חלק מאחת הישויות.

[OdedDvir]

ליתר ביאור, דוד התכוון שאפשר ליישם את הפונקציה כחלק מהאובייקט, כך:

public class Job {
   public string JobName {get; set;}
   public double WorkHours {get; set;}
   ...
   public decimal CalculatePrice()
   {
      ...
      return price;
   }
}

לעתים זו אכן הדרך הכי נוחה. אך אם הפונקציה מכילה לוגיקה עסקית שעשוייה להשתנות עם הזמן, במקרה כזה הנכון בעיני להפריד את הפונקציה מהנתונים, ולמקם אותה במחלקה אחרת שאחראית על הלוגיקה העסקית.

[dovid]

@OdedDvir לא בהכרח התכוונתי לזה, כתבתי ש"הפונקציה היא בד"כ חלק מאחת הישויות".
החלוקה שלך בין מקרה שככה נח למקרה שבה יש חלוקת בין לוגיקה לנתונים היא מצויינת וככה אני עושה לרוב, אבל היא לא עולה בקנה אחד עם עקרונות הOOP, שלפיהם פונקציה היא תמיד פעולה של ישות, למשל חישוב מחיר זה פעולה או של המוצר או של החשבונית, או של ישות של פריט בחשבונית.

[OdedDvir]

עכשיו הבנתי יותר את דבריך, ונראה לי שבעצם כיוונתי לאותו הדבר כשכתבתי

ולמקם אותה במחלקה אחרת שאחראית על הלוגיקה העסקית

כלומר, שזה תלוי בהחלטה האם הפונקציה שייכת ליישות Job או ליישות המנהלת את החשבונות הכספיים