378. Method class design pattern

קיים Design pattern נחמד וחזק שממיר פונקציות למחלקות. הרעיון הוא כזה:

נניח שיש לנו פונקציה עם חתימה כזאת:

1
2
3
4
public static IEnumerable<Person> GetPeopleByNameAndAge(string name, int age)
{
// ...
}

ניצור בנוסף ממחלקה שנראית ככה:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class GetPeopleByNameAndAgeOperation
{
public string Name
{
get;
set;
}
public int Age
{
get;
set;
}
public IEnumerable<Person> Execute()
{
// Call the original method
return GetPeopleByNameAndAge(this.Name, this.Age);
}
}

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

נוכל למשל לקרוא לפונקציה כך:

1
2
3
4
5
6
7
8
GetPeopleByNameAndAgeOperation operation =
new GetPeopleByNameAndAgeOperation()
{
Name = "Asaf",
Age = 28
};
IEnumerable<Person> results = operation.Execute();

למה זה טוב? כרגע זה נראה שזה טיפה יותר מסובך מקריאה פשוטה לפונקציה.

אז ככה:

  • קודם כל אנחנו יכולים לראות את השמות של הפרמטרים בצורה יותר ברורה
  • דבר שני, הסדר של הפרמטרים לא משנה יותר – כי הפרמטרים הם Named
  • בנוסף, אנחנו יכולים לתת ערכים דיפולטיים לפרמטרים (שימו לב שאת היתרונות האלה אנחנו מקבלים גם מNamed arguments וDefault argument values של C# 4.0)
  • היתרון המשמעותי של הDesign pattern הזה הוא שאנחנו לא חייבים להריץ את הפונקציה ישר, אלא אנחנו יכולים להריץ אותה גם בהמשך. הדבר הזה מאפשר את היתרונות הבאים:
    • אנחנו יכולים לשנות פרמטרים לפני ההרצה – אם למשל חלק מהפרמטרים לא ידועים לנו בשלב כלשהו של התכנית שלנו, אבל חלק כן, אנחנו יכולים למלא בכל חלק בתכנית את הפרמטרים שאנחנו מכירים ולהריץ את המתודה כשמילאנו את כל הפרמטרים
    • בנוסף, האופן בו אנחנו מריצים את הפונקציה הוא נתון לבחירתנו! אנחנו יכולים להחליט אם אנחנו מעוניינים בהרצה סינכרונית, או א-סינכרונית, אולי בכלל נפנה לשירות – על כל זאת אנחנו יכולה להשפיע ע"י מימוש פונקציה הרצה משלנו בתוך המחלקה!

אישית יצא לי להשתמש בPattern הזה בהקשרי GUI (יצירת Commandים) ובהרצה של Stored Procedures ע"י מחלקות Strongly-typed.

מומלץ בחום 😃

המשך יום עם מתודות שהן מחלקות טוב.

שתף