Inversion of Control ו Dependency Injection

Inversion of Control (להלן Ioc), היא תבנית עיצוב אשר ניתן להגדירה באופן כללי, כהעברת השליטה על תהליך כלשהו, כגון יצירת אובייקטים, הרצת קטע קוד וכו’, מהדרך הנקראת ‘רגילה’, על ידי תהליך מרכזי כלשהו, אל רכיב קוד אחר אשר יעשה הוא את העבודה. על ידי היפוך שליטה זה נרוויח לעיתים כמה דברים, כפי שתיכף ניראה.

את IoC אפשר לממש בכל מיני דרכים בהתאם לתהליך עליו אנחנו עובדים, אך הכלי שבעזרתו מממשים IoC הוא תבנית עיצוב נוספת בשם Dependency Injection.

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

ולפעמים נשתמש בIoC על מנת לשנות את התהליך ‘הרגיל’ של התוכנה. במילה ‘רגיל’ אני מתכוון לתהליך שעובד באופן פרוצדורלי – ניתן לתאר זאת באמצעות ההבדל שבין Console Application שבה נשאלת שאלה ומתקבלת תשובה וחוזר חלילה, ושהשליטה על התהליך היא של התוכנה עצמה, לבין WinForm שבו יש תוויות עם שאלות ושדות להכנסת תשובות ולחיצה על כפתור שבה המשתמש הוא זה שמפעיל תהליך על ידי שליחת תשובות.

דרך זו ידועה באימרה – “Don’t call us, we’ll call you!!”

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

Dependency Injection

DI (הזרקת תלויות) הוא סוג של IOC – זוהי תבנית עיצוב שבה אנו יוצרים או משייכים אובייקטים שהמחלקה שלנו תלויה בהם – מחוץ למחלקה.

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

בדרך כלל הזרקת התלויות תתרחש דרך ה Construcor.

דוגמא:

נניח שיש לי מחלקה בשם Till המתארת התנהגות של קופה בחנות, והיא צריכה להשתמש באמצעי תשלום. אני יוצר Interface בשם ITender, וכל אמצעי התשלום שלי מממשים אותו. ב Constructor של Till נצטרך ‘להזריק’ את אמצעי התשלום בו אנו רוצים להשתמש.

הקוד נראה כך:

ITender tender = new CreditCard();
Till till = new Till(tender);
    public class Till
    {
        private readonly ITender _tender;
    
        public Till(ITender tender)
        {
        _tender = tender;
        }
    }

וכך באופן פשוט ביותר מימשנו DI.

ישנה אפשרות לממש DI לא על ידי ה Constructor אלא על ידי Setter של Property, באופן הבא:

ITender tender = new CreditCard();
Till till = new Till();
till.Tender = tender;
    public class Till
    {
      public ITender Tender { get; set; }
    }
  

במקרה כזה צריך להזהר לא להשתמש בשדה הזה לפני שהוא אותחל.

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

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

כמה חסרונות של DI הם:

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

ב. אנחנו יוצרים את התלויות שלנו לפני שאנחנו באמת צריכים אותם.

ג. והנה חסרון שהוא גם יתרון – יותר קל לעשות unit test במקרה של DI בגלל של Interface אפשר לעשות Moq, אבל זה גם החיסרון, מכיוון שיתכן ולא נבדוק כראוי את מה שתכננו לבדוק.

בניית IoC

באופן כללי ניתן להגדיר ש IoC היא תשתית לצורך עבודה עם Dependency Injection. מהסיבה הזו יש כמה תשתיות מוכנות כגון UNITY של מיקרוסופט או castle of Windsor אשר חוסכות לנו לכתוב את התשתית בכל פעם מחדש.

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

נשתמש בקוד מהדוגמא של DI.

הקוד נראה כך:

   1: class Program

   2: {

   3:     static void Main(string[] args)

   4:     {

   5:         ITender tender = new CreditCard();

   6:         Till till = new Till(tender);

   7:     }

   8: }

9:

  10: public class Till

  11: {

  12:     private readonly ITender _tender;

13:

  14:     public Till(ITender tender)

  15:     {

  16:         _tender = tender;

  17:     }

  18: }

19:

  20: public class CreditCard : ITender

  21: {

  22: }

23:

  24: public interface ITender

  25: {

  26: }

כעת נעשה כמה שינויים.

נוסיף מתודת Charge במחלקה Till ומתודה זו תקרא למתודה זהה הקיימת בכל מי שמממש את ITender. מתודה זו מדפיסה הודעה כלשהי.

כמו כן ניצור בשביל הדוגמא עוד מחלקה בשם Cash לתשלום במזומן – גם מחלקה זו כמובן יורשת מ ITender.

public class Till
{
    private readonly ITender _tender;
  
    public Till(ITender tender)
    {
        _tender = tender;
    }
  
    public string Charge()
    {
        return _tender.Charge();
    }
}
  
public class CreditCard : ITender
{
    public string Charge()
    {
        return "CreditCard";
    }
}
public class Cash : ITender
{
    public string Charge()
    {
        return "Cash";
    }
}
  
public interface ITender
{
    string Charge();
} 

כעת כמובן שנוכל להחליט האם אנחנו שולחים בConstructor של הקופה תשלום במזומן או באשראי וההודעה תודפס בהתאם.

אבל – זה עדיין לא כל כך נוח. הייתי מעדיף שלא להחליט בתוך הקוד באיזה אמצעי תשלום להשתמש אלא שמישהו אחר יעשה זאת עבורי. שאוכל לקרוא לאיזושהי מחלקה עם מתודה מסויימת והיא כבר תחזיר לי את אמצעי התשלום בדרך כלשהי. וכך אוכל למשל לשמור את אמצעי התשלום בקובץ XML או באופן אחר.

אם כך, אני מייצר מחלקה בשם Resolver ובה יש מתודה בשם ResolveTender המחזירה אובייקט מסוג ITender.

בעולם האמיתי תהיה לוגיקה הגיונית שתחליט מה להחזיר או מקור נתונים כלשהו, אבל בשביל הדוגמא כתבתי תנאי משתנה (האם השנייה כרגע זוגית או אי זוגית) כאשר בכל מקרה היא מחזירה אובייקט אחר.

המחלקה ניראת כך:

   1: public class Resolver

   2: {

   3:     public ITender ResolveTender()

   4:     {

   5:         if (DateTime.Now.Second % 2 == 0)

   6:         {

   7:             return new CreditCard();

   8:         }

   9:         else

  10:         {

  11:             return new Cash();

  12:         }

  13:     }

  14: }

והשימוש בה יהיה כך:

   1: Resolver resolver = new Resolver();

   2: Till till = new Till(resolver.ResolveTender());

   3: var message = till.Charge();

   4: Console.WriteLine(message);

כעת, אם נריץ את התוכנה הקטנה שלנו היא תדפיס לפעמים Cash ולפעמים CreditCard.

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

   1: Till till = new Till(resolver.ResolveTender());

משהו שנראה יותר דומה לזה

   1: Till till = resolver.Resolve<Till>();

בשביל שדבר כזה יעבוד נצטרך קצת Reflection.

ראשית ניצור Dictionary שבעזרתו נמפה את האובייקטים שלנו.

השורה תיראה כך:

   1: private Dictionary<Type,Type> _map = new Dictionary<Type, Type>();

כאשר הType הראשון מסמן את האינטרפייס (ITender במקרה שלנו)

והType השני מסמן מימוש קונקרטי שלו (למשל Cash)

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

נעשה את זה על ידי שימוש ב typeof.

במתודה החדשה שיצרנו נבדוק אם הType שקיבלנו נמצא בתוך ה Dictionary שלנו ואם לא נזרוק הודעת שגיאה.

Type resolvedType = null;
try
{
    resolvedType = _map[typeToResolve];
}
catch (Exception)
{
    throw new Exception(string.Format("Could not find {0}", typeToResolve.FullName));
}

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

נתחיל במקרה הפשוט שבו אין פרמטרים.

ל Type יש מתודה בשם GetConstructors שתחזיר לנו (בתוספת First ) את הConstructor הראשון. ואז נוכל לבדוק מהם הפרמטרים על ידי שימוש במתודה GetParameters.

עכשיו ניצור תנאי –

אם אין לי פרמטרים אייצר מופע מהסוג שקיבלתי באופן הבא:

   1: Activator.CreateInstance(resolvedType);

Activator מאפשר לי ליצור מופע חדש, בדיוק כמו במילה New, אלא שהיא עושה את זה כנגד Type.

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

IList<object> parameters = new List<object>();
foreach (var constructorParameter in constructorParameters)
{
    parameters.Add(Resolve(constructorParameter.ParameterType));
}

כעת לא נוכל להשתמש בActivator כדי ליצור מופע חדש אלא נשתמש במתודת invoke המקבלת מערך של פרמטרים.

   1: return firstConstructor.Invoke(parameters.ToArray());

כעת יש לנו Container של IoC שיצרנו בעצמנו.

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

לצורך המיפוי ניצור ב IoC שלנו מתודת Register המקבלת את המיפוי ומוסיפה לDictionary באופן הבא:

public void Register<TFrom, TTo>()
{
    _map.Add(typeof(TFrom), typeof(TTo));
}

נצטרך לעשות את זה גם למחלקת Till – שממופה לעצמה.

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

   1: resolver.Register<Till, Till>();
   2: resolver.Register<ITender, Cash>()

כעת נוכל להריץ את הקוד ולקבל את התוצאה הרצויה.

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

הקוד בכללותו למי שמעוניין:

using System;
using System.Collections.Generic;
using System.Linq;
  
namespace ConsoleApplication5
{
    class Program
    {
        static void Main()
        {
          var resolver = new Resolver();
            resolver.Register<Till, Till>();
            resolver.Register<ITender, Cash>();
            resolver.Register<ITender, CreditCard>();
            var till = resolver.Resolve<Till>();
            var message = till.Charge();
            Console.WriteLine(message);
            Console.Read();
  
        }
    }
  
    public class Resolver
    {
      private Dictionary<Type, Type> _map = new Dictionary<Type, Type>();
        public T Resolve<T>()
        {
            return (T)Resolve(typeof(T));
        }
  
        private object Resolve(Type typeToResolve)
        {
            Type resolvedType;
            try
            {
                resolvedType = _map[typeToResolve];
            }
            catch (Exception)
            {
                throw new Exception(string.Format("Could not find {0}", typeToResolve.FullName));
            }
            var firstConstructor = resolvedType.GetConstructors().First();
            var constructorParameters = firstConstructor.GetParameters();
            if (!constructorParameters.Any())
            {
                return Activator.CreateInstance(resolvedType);
            }
  
            IList<object> parameters = constructorParameters.Select(constructorParameter => Resolve(constructorParameter.ParameterType)).ToList();
            return firstConstructor.Invoke(parameters.ToArray());
        }
  
        public void Register<TFrom, TTo>()
        {
            _map.Add(typeof(TFrom), typeof(TTo));
        }
    }
  
    public class Till
    {
        private readonly ITender _tender;
  
        public Till(ITender tender)
        {
            _tender = tender;
        }
  
        public string Charge()
        {
            return _tender.Charge();
        }
    }
  
    public class CreditCard : ITender
    {
        public string Charge()
        {
            return "CreditCard";
        }
    }
    public class Cash : ITender
    {
        public string Charge()
        {
            return "Cash";
        }
    }
  
    public interface ITender
    {
        string Charge();
    }
}