Author: Jarosław Stadnicki

Własna konfiguracja w app.config

~ Jarosław Stadnicki ~ 4 Comments

Jeśli to czytacie, to znaczy że zdążyłem jeszcze z wpisem przed nowym rokiem.  Udało mi się napisać jeszcze jednego posta przed nowym rokiem – jestem królem świata!

Dzisiaj o wykorzystaniu app.config dla własnych celów. Skąd taki pomysł? Otóż jak każdy pewnie ma lub miał w życiu, czasem mieć taką potrzebę aby zmieniać zachowanie aplikacji inaczej niż przez jej przekompilowanie. Wtedy właśnie z pomocą przychodzą pliki .txt, .xml, .config czy dawno dawno temu .ini. Można napisać własne system do obsługi konfiguracji, własne klasy serializujące i deserializujące, można pisać cudne rzeczy. Ale po co, skoro można skorzystać z tego co oferuje app.config. Też tak pomyślałem i rozpętało się piekło. Bo nie da się ot tak dowalić do app.configu swojego kawałka xmla. Trzba to wszystko dokładnie, ale to dokładnie opisać. O ile wytrzymacie ten wpis, to zaraz wszystko wyjaśnię.

Zacznę od początku na prostych obiektach. Np. gdybym chciał w pliku zdefiniować wygląd jakiegoś prostego obiektu, np.

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: Consolas, “Courier New”, Courier, Monospace;
background-color: #ffffff;
/*white-space: pre;*/
}

.csharpcode pre { margin: 0em; }

.csharpcode .rem { color: #008000; }

.csharpcode .kwrd { color: #0000ff; }

.csharpcode .str { color: #a31515; }

.csharpcode .op { color: #0000c0; }

.csharpcode .preproc { color: #cc6633; }

.csharpcode .asp { background-color: #ffff00; }

.csharpcode .html { color: #800000; }

.csharpcode .attr { color: #ff0000; }

.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}

.csharpcode .lnum { color: #606060; }

   1:  <?xml version="1.0" encoding="utf-8" ?>
   2:  <configuration>
   3:      <MyConfiguration>
   4:          <Rectangle Color="Red" Width="10" Height="5" Fill="False"/>
   5:      </MyConfiguration>
   6:  </configuration>

Wiecie co się stanie przy próbie uruchomienia takiego prostego kodu jak ten:

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: Consolas, “Courier New”, Courier, Monospace;
background-color: #ffffff;
/*white-space: pre;*/
}

.csharpcode pre { margin: 0em; }

.csharpcode .rem { color: #008000; }

.csharpcode .kwrd { color: #0000ff; }

.csharpcode .str { color: #a31515; }

.csharpcode .op { color: #0000c0; }

.csharpcode .preproc { color: #cc6633; }

.csharpcode .asp { background-color: #ffff00; }

.csharpcode .html { color: #800000; }

.csharpcode .attr { color: #ff0000; }

.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}

.csharpcode .lnum { color: #606060; }

   1:  static void Main(string[] args)
   2:  {
   3:      var cfg = ConfigurationManager.AppSettings;
   4:  }

Aby konfiguracja zadziałała, trzeba dodać informację do app.cofig o naszej sekcji konfiguracyjnej.

   1:  <configSections>
   2:      <section name="MyConfiguration" type="AppConfigExample.MyConfiguration, AppConfigExample"/>
   3:  </configSections>

W części type podajemy gdzie znajdzie się klasa opisująca naszą konfigurację. Wpis musi zawierać pełny namespace, następnie należy podać także assembly w który się ona znajduje. Tutaj wszystko mam w jednym assembly.
Skoro trzeba podać klasę to trzeba ją także gdzieś i jakoś zdefiniować i podziedziczyć:

   1:  public class MyConfiguration : ConfigurationSection
   2:  {
   3:  }

A następnie spróbować się do niej dostać:

   1:  var cfg = ConfigurationManager.GetSection("MyConfiguration");

Niestety to nadal za mało (powoli buduje nastrój grozy):

Lubię .net i jego wyjątki za czytelne błędy i opisy problemów, lubię też google czy SO za pomoc w rozwiązywaniu tych wyjątków. Chwila szukania i już wiem co należy dodać, aby móc odczytać mój kwadracik z konfiguracji:

   1:  public class MyConfiguration : ConfigurationSection
   2:  {
   3:      [ConfigurationProperty("Rectangle")]
   4:      public Rectangle Rectangle
   5:      {
   6:          get { return ((Rectangle)(base["Rectangle"])); }
   7:      }
   8:  }

Skoro wspominamy tutaj o klasie Rectangle to należy ją także jakoś zdefiniować i znowu dziedziczenie:

   1:  public class Rectangle: ConfigurationElement
   2:  {
   3:      [ConfigurationProperty("Color")]
   4:      public ConsoleColor Color
   5:      {
   6:          get { return (ConsoleColor)base["Color"]; }
   7:          set { base["Color"] = value; }
   8:      }
   9:   
  10:      [ConfigurationProperty("Width")]
  11:      public int Width
  12:      {
  13:          get { return (int)base["Width"]; }
  14:          set { base["Width"] = value; }
  15:      }
  16:   
  17:      [ConfigurationProperty("Height")]
  18:      public int Height
  19:      {
  20:          get { return (int)base["Height"]; }
  21:          set { base["Height"] = value; }
  22:      }
  23:   
  24:      [ConfigurationProperty("Fill")]
  25:      public bool Fill
  26:      {
  27:          get { return (bool)base["Fill"]; }
  28:          set { base["Fill"] = value; }
  29:      }
  30:  }

Gdy mamy taki kod możemy spokojnie spróbować swoich sił i uruchomić coś takiego:

   1:  var cfg = ConfigurationManager.GetSection("MyConfiguration") as MyConfiguration;
   2:   
   3:  var oc = Console.ForegroundColor;
   4:  Console.ForegroundColor = cfg.Rectangle.Color;
   5:   
   6:  Console.WriteLine("Width:{0}, Height:{1}, Filled:{2}", cfg.Rectangle.Width, cfg.Rectangle.Height,
   7:                    cfg.Rectangle.Fill);
   8:   
   9:  Console.ForegroundColor = oc;
Co powinno dać taki wynik:

Chyba nie macie dosyć? Nie warto zaprzestawać na tylko jednym takim obiekcie, skoro na świecie jest tyle pięknych prostokątów, załóżmy taki przypadek:

   1:  <MyConfiguration>
   2:      <Rectangle Color="Red" Width="10" Height="5" Fill="False"/>
   3:      <Rectangle Color="Green" Width="12" Height="6" Fill="False"/>
   4:      <Rectangle Color="Black" Width="14" Height="3" Fill="True"/>
   5:      <Rectangle Color="White" Width="15" Height="2" Fill="True"/>
   6:      <Rectangle Color="Gray" Width="16" Height="10" Fill="False"/>
   7:  </MyConfiguration>

Co się stanie po uruchomieniu aplikacji z taką konfiguracją?

No racja racja, przecież to kolekcja prostokątów, powinna wyglądać inaczej, bo skąd biedny komputerek może wiedzieć o który obiekt dokładnie nam chodzi.

Macie tak czasami, że wy wiecie że się nie uda czegoś zrobić, a komputer jeszcze walczy? Np. klikniecie przez przypadek na napędzie CD, tam nie ma płyty, wszyscy to wiedzą, ale nie, 15 sekund trzeba czekać zanim komputerek też się dowie. Sieć nie działa, wszyscy wiedzą, a komp walczy. Najgorsze jest to że się nie uczy. Skoro nie było płyty, i napęd się nie wysunął i nie wsunął, to płyty nadal tam nie będzie. Ale kliknij znowu na ikonę z CD i znowu czekasz, bo może jednak jest. Ech takie szybkie i takie głupie.

Wracając do naszego problemu, jak zrobić żeby ten biedny komputerek poradził sobie z wieloma prostokącikami:

   1:  <Rectangles>
   2:      <Rectangle Color="Red" Width="10" Height="5" Fill="False"/>
   3:      <Rectangle Color="Green" Width="12" Height="6" Fill="False"/>
   4:      <Rectangle Color="Black" Width="14" Height="3" Fill="True"/>
   5:      <Rectangle Color="White" Width="15" Height="2" Fill="True"/>
   6:      <Rectangle Color="Gray" Width="16" Height="10" Fill="False"/>
   7:  </Rectangles>

Ale wtedy znowu będzie marudzić, że unrecognized element i że “Rectangles” to ten unrecognized. Trzeba więc zaktualizować informację z klasie MyConfiguration na taki:

   1:  public class MyConfiguration : ConfigurationSection
   2:  {
   3:      [ConfigurationProperty("Rectangles")]
   4:      public Rectangles Rectangles
   5:      {
   6:          get { return ((Rectangles)(base["Rectangles"])); }
   7:      }
   8:  }

Oraz zdefiniować odpowiednio klasę Rectangles. Możecie spróbować samodzielnie ją zdefiniować i zobaczyć jaki poleci wyjątek, lub też przeczytać dalej i zobaczyć jak robią to inni:

   1:  [ConfigurationCollection(typeof(Rectangle))]
   2:  public class Rectangles : ConfigurationElementCollection
   3:  {
   4:      protected override ConfigurationElement CreateNewElement()
   5:      {
   6:          return new Rectangle();
   7:      }
   8:   
   9:      protected override object GetElementKey(ConfigurationElement element)
  10:      {
  11:          return element.GetHashCode();
  12:      }
  13:  }

Linijka 11 nie wygląda najlepiej. A poza tym może spowodować błąd (podczas domyślnej implementacji GetHashCode), aby go uniknąć należy napisać własne GetHashCode w klasie Rectangle lub dołożyć jakiś klucz, co później ułatwi dostęp do wybranych elementów z kolekcji.
Klasę Rectangle należy uaktualnić o następujące pole:

   1:  [ConfigurationProperty("Id", IsKey = true, IsRequired = true)]
   2:  public int Id
   3:  {
   4:      get { return (int)base["Id"]; }
   5:      set { base["Id"] = value; }
   6:  }

Natomiast metoda GetElementKey wyglądać teraz będzie tak:

   1:  protected override object GetElementKey(ConfigurationElement element)
   2:  {
   3:      return ((Rectangle)element).Name;
   4:  }

Kolekcja elementów w app.config wygląda teraz tak:

   1:  <Rectangles>
   2:      <add Id="1" Color="Red" Width="10" Height="5" Fill="False"/>
   3:      <add Id="2" Color="Green" Width="12" Height="6" Fill="False"/>
   4:      <add Id="3" Color="Black" Width="14" Height="3" Fill="True"/>
   5:      <add Id="4" Color="White" Width="15" Height="2" Fill="True"/>
   6:      <add Id="5" Color="Gray" Width="16" Height="10" Fill="False"/>
   7:  </Rectangles>

I znowu coś nie cool, to idiotyczne add – bleh, brzydal. Gdzie się podziało ładne Rectangle? Ponownie zachęcam do sprawdzenia wyjątku jaki leci, gdy zamiast add będzie Rectangle. Na szczęście i to da się napisać lepiej, wystarczy ponownie zaktualizować informację o klasie Rectangles, brakuje tam małej informacji w atrybutach klasy:

   1:  [ConfigurationCollection(typeof(Rectangle), AddItemName = "Rectangle")]
   2:  public class Rectangles : ConfigurationElementCollection { /* unicorns here */ }

Od teraz znowu zamiast add możemy stosować Rectangle i uruchomić taki kod:

   1:  var cfg = ConfigurationManager.GetSection("MyConfiguration") as MyConfiguration;
   2:  var oc = Console.ForegroundColor;
   3:   
   4:  foreach (Rectangle rectangle in cfg.Rectangles)
   5:  {
   6:      Console.ForegroundColor = rectangle.Color;
   7:      Console.WriteLine("Width:{0}, Height:{1}, Filled:{2}", rectangle.Width, rectangle.Height,rectangle.Fill);
   8:      Console.ForegroundColor = oc;
   9:  }

Co według mojego działania da taki wynik:

A ja wybrać ten jeden w swoim rodzaju Rectangl? Skoro mamy jego Id to powinniśmy z niego jakoś skorzystać. Może linq? Potrzebujemy tylko IEnumerable w klasie Rectangles i będzie działać, a więc:

   1:  [ConfigurationCollection(typeof(Rectangle), AddItemName = "Rectangle")]
   2:  public class Rectangles: ConfigurationElementCollection, IEnumerable<Rectangle>
   3:  {
   4:      { /* dragons here */ }
   5:      public new IEnumerator<Rectangle> GetEnumerator()
   6:      {
   7:          int count = base.Count;
   8:          for (int i = 0; i < count; i++)
   9:          {
  10:              yield return base.BaseGet(i) as Rectangle;
  11:          }
  12:      }
  13:  }

I można już napisać coś takiego w kodzie:

   1:  Rectangle rect = cfg.Rectangles.Single(r => r.Id == 2);
   2:   
   3:  Console.ForegroundColor = rect.Color;
   4:  Console.WriteLine("Width:{0}, Height:{1}, Filled:{2}", rect.Width, rect.Height, rect.Fill);

Od teraz wszyscy mogą zazdrościć wam wiedzy o tym, jak lepiej wykorzystywać app.config w swoich aplikacjach.

A teraz cały kod z wpisu:

   1:  using System;
   2:  using System.Collections.Generic;
   3:  using System.Configuration;
   4:  using System.Linq;
   5:  using System.Text;
   6:   
   7:  namespace AppConfigExample
   8:  {
   9:      class Program
  10:      {
  11:          static void Main(string[] args)
  12:          {
  13:              var cfg = ConfigurationManager.GetSection("MyConfiguration") as MyConfiguration;
  14:              var oc = Console.ForegroundColor;
  15:   
  16:              foreach (Rectangle rectangle in cfg.Rectangles)
  17:              {
  18:                  Console.ForegroundColor = rectangle.Color;
  19:                  Console.WriteLine("Width:{0}, Height:{1}, Filled:{2}", rectangle.Width, rectangle.Height, rectangle.Fill);
  20:              }
  21:   
  22:              Console.WriteLine("****************************************");
  23:              Rectangle rect = cfg.Rectangles.Single(r => r.Id == 2);
  24:   
  25:              Console.ForegroundColor = rect.Color;
  26:              Console.WriteLine("Width:{0}, Height:{1}, Filled:{2}", rect.Width, rect.Height, rect.Fill);
  27:   
  28:   
  29:   
  30:              Console.ForegroundColor = oc;
  31:          }
  32:      }
  33:   
  34:   
  35:      public class MyConfiguration : ConfigurationSection
  36:      {
  37:          [ConfigurationProperty("Rectangles")]
  38:          public Rectangles Rectangles
  39:          {
  40:              get { return ((Rectangles)(base["Rectangles"])); }
  41:          }
  42:      }
  43:   
  44:      [ConfigurationCollection(typeof(Rectangle), AddItemName = "Rectangle")]
  45:      public class Rectangles : ConfigurationElementCollection, IEnumerable<Rectangle>
  46:      {
  47:          protected override ConfigurationElement CreateNewElement()
  48:          {
  49:              return new Rectangle();
  50:          }
  51:   
  52:          protected override object GetElementKey(ConfigurationElement element)
  53:          {
  54:              return ((Rectangle)element).Id;
  55:          }
  56:   
  57:          public new IEnumerator<Rectangle> GetEnumerator()
  58:          {
  59:              int count = base.Count;
  60:              for (int i = 0; i < count; i++)
  61:              {
  62:                  yield return base.BaseGet(i) as Rectangle;
  63:              }
  64:          }
  65:      }
  66:   
  67:      public class Rectangle : ConfigurationElement
  68:      {
  69:          [ConfigurationProperty("Id", IsKey = true, IsRequired = true)]
  70:          public int Id
  71:          {
  72:              get { return (int)base["Id"]; }
  73:              set { base["Id"] = value; }
  74:          }
  75:   
  76:          [ConfigurationProperty("Color")]
  77:          public ConsoleColor Color
  78:          {
  79:              get { return (ConsoleColor)base["Color"]; }
  80:              set { base["Color"] = value; }
  81:          }
  82:   
  83:          [ConfigurationProperty("Width")]
  84:          public int Width
  85:          {
  86:              get { return (int)base["Width"]; }
  87:              set { base["Width"] = value; }
  88:          }
  89:   
  90:          [ConfigurationProperty("Height")]
  91:          public int Height
  92:          {
  93:              get { return (int)base["Height"]; }
  94:              set { base["Height"] = value; }
  95:          }
  96:   
  97:          [ConfigurationProperty("Fill")]
  98:          public bool Fill
  99:          {
 100:              get { return (bool)base["Fill"]; }
 101:              set { base["Fill"] = value; }
 102:          }
 103:      }
 104:  }

Oraz app.config:

   1:  <?xml version="1.0" encoding="utf-8" ?>
   2:  <configuration>
   3:      <configSections>
   4:          <section name="MyConfiguration" type="AppConfigExample.MyConfiguration, AppConfigExample"/>
   5:      </configSections>
   6:      <MyConfiguration>
   7:          <Rectangles>
   8:              <Rectangle Id="1" Color="Red" Width="10" Height="5" Fill="False"/>
   9:              <Rectangle Id="2" Color="Green" Width="12" Height="6" Fill="False"/>
  10:              <Rectangle Id="3" Color="Black" Width="14" Height="3" Fill="True"/>
  11:              <Rectangle Id="4" Color="White" Width="15" Height="2" Fill="True"/>
  12:              <Rectangle Id="5" Color="Gray" Width="16" Height="10" Fill="False"/>
  13:          </Rectangles>
  14:      </MyConfiguration>
  15:  </configuration>

To by było na tyle, bierzcie i korzystajcie z tego, bo to dobre jest.
Pozostaje mi tylko życzyć dobrego w nadchodzącym nowym roku!
Tej!

Czym się różni właściwość klasy od pola klasy?

~ Jarosław Stadnicki ~ 3 Comments

Wracając jeszcze do filozofowania o kodzie, dziś trochę o cechach klas, a dokładniej: pola i właściwości. Zanim wymyślono idee właściwości dostęp do pól odbywał się na dwa sposoby. Pole w klasie (np. name) mogło być publiczne i każdy miotał nim jak szatan, druga opcja to dostęp kontrolowany przez parę metod typu GetName i SetName. Umożliwiały one kontrolowanie tego kto i na jakich zasadach może korzystać z cech wewnętrznych klasy.
Później, aby pominąć pisanie GetName/SetName, wymyślono właściwości, które w sprytny sposób, miały pozbyć się z kodu klienta getów i setów, czyniąc kod bardziej czytelnym. Jednocześnie pozostawić możliwość kontrolowanie kto i jak ma dostęp do pola, poprzez “ukrytą” implementację tychże get i set. Wygląda więc to tak, że klient korzysta z naszego pola w klasie, które naprawdę jest jest właściwością opakowującą to pole. Zresztą każdy wie jak wygląda i działa właściwość w C#.
Teraz czas na właściwą filozofię, czym się różni właściwość klasy od pola w klasie?

  1. Właściwość może zostać tak zaimplementowana, aby była tylko do zapisu lub tylko do odczytu. Pole w klasie jest najczęściej implementowane czytalne/pisalne (uwielbiam nowo mowę). Czasem tworzy się stałe. (ot czasami tak trzeba).
  2. Właściwość podczas zapisu lub odczytu może nas poczęstować wybornym wyjątkiem, ta sama operacja wykonana na polu nigdy.
  3. Właściwość nie może zostać przekazana jako ref lub out argument metody, pole klasy tak.
  4. Czas wykonania właściwości może być czasem bardzo długi, np. podczas wykonywania synchronizacji wątków, leniwej inicjalizacji właściwości, etc. Dostęp do pola zawsze jest operacją natychmiastową.
  5. Dostęp do właściwości może powodować efekty uboczne, np. w cache, każdy dostęp może zmniejszać czas życia keszu. Dostęp do pola nigdy nie ma takiej możliwości.
  6. Odczytanie właściwości klasy czasem może się wymagać zwiększania zapotrzebowania na pamięć RAM, potrzebę na przeliczenie pewnych zależności, czy wykonanie dodatkowych operacji, może także zwrócić nie pełny wynik. Dostęp do pola, nie wymaga dodatkowych środków, oraz zwraca oryginalną zawartość tego pola.

Nasuwa się pytanie, czy wy będąc klientem klasy X, która oferuje dostęp do właściwości, oczekujecie, że dostęp do właściwości Name będzie:

  • trwał strasznie długo
  • każdy operacja odczytu zmienia, zwraca inną wartość
  • dostaniecie tylko spółgłoski
  • zanim dostaniecie wynik, zużycie pamięci wzrośnie o kilkanaście mega

Takich rzeczy można oczekiwać od metod, to one powinny robić coś skomplikowanego, dostęp do pola powinien być możliwie szybki i prosty. Warto o tym pamiętać, pisząc swój kawałek kodu. Może trzeba wrócić do poczciwego GetName(), GetNameConsonantsOnly(),
GetNameVowelsOnly(), GetNameUsing5MbRamMore() ?

Ot takie tam żywcem zerżnięte informacje z książki którą czytam i pomyślałem, że warto o tym napisać.

ps.
DateTime.Now 😉

Przyjemne funkcje

~ Jarosław Stadnicki ~ 3 Comments

Jak przyjmować i jak zwracać kulturalnie – zastanawialiście się kiedyś na tym? Taki programistyczny savoir-vivre. Jak to zrobić, żeby mi (programiście) było wygodnie, a jednocześnie uszcześliwić przyszłego użytkownika API które tworzymy? Przecież to może być właśnie ja (ja piszący tego bloga)!

Sprzedam wam dwie proste reguły (na bank są inne o których nie wiem), które warto zapamiętać lub przynajmniej sie nad nimi zastanowić.

Przyjmowany parametr powinien być możliwie wysoko w drzewie dziedziczenia, możliwie najogólnieszy, z którego możemy skorzystać. Jak zawsze będę się wspierać na przejaskrawionych przykładach, zupełnie oderwanych od rzeczywistości:

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: Consolas, “Courier New”, Courier, Monospace;
background-color: #ffffff;
/*white-space: pre;*/
}

.csharpcode pre { margin: 0em; }

.csharpcode .rem { color: #008000; }

.csharpcode .kwrd { color: #0000ff; }

.csharpcode .str { color: #a31515; }

.csharpcode .op { color: #0000c0; }

.csharpcode .preproc { color: #cc6633; }

.csharpcode .asp { background-color: #ffff00; }

.csharpcode .html { color: #800000; }

.csharpcode .attr { color: #ff0000; }

.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}

.csharpcode .lnum { color: #606060; }

   1:  int NotSoNiceSumFunction(List<int> arg)
   2:  {
   3:      int result = 0;
   4:      foreach (var i in arg)
   5:      {
   6:          result += i;
   7:      }
   8:      return result;
   9:  }

Oraz drugi przyklad:

   1:  int NiceSumFunction(IEnumerable<int> arg)
   2:  {
   3:      int result = 0;
   4:      foreach (var i in arg)
   5:      {
   6:          result += i;
   7:      }
   8:      return result;
   9:  }

Zasadniczo nie różnią się one od siebie poza typem arugumentu. Za pierwszym razem określamy go bardzo dokładnie: pracujemy tylko z listą intów. Podczas gdy w seksownym ciele funkcji, nie ma nigdzie zachowania, które mogłoby uzasadnić potrzebę używania listy. Za drugim razem, wymagamy tylko aby argument implementował interfejs IEnumerable.
Jaki jest zysk z takiego pozytywnego nastawienia?

   1:  void Test(string[] args)
   2:  {
   3:      List<int> input1 = new List<int>();
   4:      IList<int> input2 = new List<int>();
   5:      ICollection<int> input3 = new List<int>();
   6:      IEnumerable<int> input4 = new List<int>();
   7:      int[] input5 = new int[100];
   8:   
   9:      NotSoNiceSumFunction(input1); // :)
  10:      NotSoNiceSumFunction(input2); // :(
  11:      NotSoNiceSumFunction(input3); // :(
  12:      NotSoNiceSumFunction(input4); // :(
  13:      NotSoNiceSumFunction(input5); // :(
  14:   
  15:      NiceSumFunction(input1); // :)
  16:      NiceSumFunction(input2); // :)
  17:      NiceSumFunction(input3); // :)
  18:      NiceSumFunction(input4); // :)
  19:      NiceSumFunction(input5); // :)
  20:  }

Powyżej przykładowy kod z różnymi kontenerami dla intów. Które linijki kodu nie będą chciały banglać? Mój kompilator nie poradził sobie z linijkami 10,11,12,13. Czyli tak jak powiedzieliśmy podczas definiowania funkcji NotSoNiceSumFunction – działamy tylko i wyłącznie z listą intów. Podczas gdy NiceSumFunction poradził sobie z każdym rodzajem parametru. Chyba nie muszę pisać z kim będzie się lepiej współpracowało?

Teraz w drugą stronę, jest juz po wszystkim, wiatraczek wyje, procek gorący, mamy wynik. Jak go przekazać stronie zainteresowanej? Zwrócić jako ogólny typ, czy dokładnie określić co nam wyszło? Myśl, myśl, myśl.

Znowu kod dla przykładu:

   1:  List<int>  GetAllItemsAsList()
   2:  {
   3:      List<int> items = new List<int>();
   4:      // magic goes here
   5:      return items;
   6:  }

Wersja mniej szczegółowa:

   1:  static IEnumerable<int>  GetAllItemsAsEnum()
   2:  {
   3:      IEnumerable<int> items = new List<int>();
   4:      // magic goes here
   5:      return items;
   6:  }

Na którą wersję się decydujecie? Ja przyznam się szczerze, że do tej pory wynik zwracałem zawsze przez IEnumerable. Ale już tak nie robię.
Jak może wyglądać wykorzystanie metod ze strony klienta na przykładach:

   1:  void Test(string[] args)
   2:  {
   3:      List<int> result1 = null;
   4:      IList<int> result2 = null;
   5:      ICollection<int> result3 = null;
   6:      IEnumerable<int> result4 = null;
   7:      int[] result5 = null;
   8:   
   9:   
  10:      result1 = GetAllItemsAsList(); // :)
  11:      result2 = GetAllItemsAsList(); // :)
  12:      result3 = GetAllItemsAsList(); // :)
  13:      result4 = GetAllItemsAsList(); // :)
  14:      result5 = GetAllItemsAsList(); // :(
  15:                                    
  16:      result1 = GetAllItemsAsEnum(); // :(
  17:      result2 = GetAllItemsAsEnum(); // :(
  18:      result3 = GetAllItemsAsEnum(); // :(
  19:      result4 = GetAllItemsAsEnum(); // :)
  20:      result5 = GetAllItemsAsEnum(); // :(
  21:  }

W tym przypadku widać, że klient będzie bardziej szczęśliwy jeśli dokładnie określimy wynik naszej pracy, a decyzję o tym co z nim zrobić zostawimy końcowemu odbiorcy. W przypadku zwracania jako enum, klient będzie musiał przyjąć IEnumerable, a następnie samodzielnie przekształcić to, w razie potrzeby, w klasą bardziej wyspecjalizowaną.

Czyli co, bądźmy mili i proaktywni, przyjmujmy wszystko z czym możemy sobie poradzić. A zwracając wynik, zadbajmy o szczegółową informację o tym, czym jest wynik i jak z niego korzystać, klient sam podejmie najlepszą decyzję czy wykorzysta pełny potencjał naszej ciężkiej pracy, czy potrakutje nas po między mordziu.

Pozdrawiam z IE8 i czekam na riposty.

NDepend4 – co potrafi statyczna analiza kodu.

~ Jarosław Stadnicki ~ 1 Comment

Dostałem NDepend4 w zamian za jego opis 🙂 Nie muszę o nim mówić w samych słodkich komentarzach, także można wpis czytać do końca.
NDepend służy to statycznej analizy kodu napisanego w .NET. Potrafi ocenić kod po wieloma względami, np: ze względu na skomplikowanie, ilość linii kod czy instrukcji IL, ilość zmiennych, łatwość modyfikacji, może zasugerować zmianę typów z referencyjnych na wartościowe (ref type –> value type).
Sama instalacja jest banalnie prosta, ściągamy paczkę ze strony, rozpakowujemy oraz wrzucamy plik z licencją :> Chyyyba że jej nie macie, wtedy można skorzystać z darmowej wersji 14 dniowej. To wszystko, potem wystarczy odpalić i załadować plik z solucją, którą chcielibyśmy się bliżej przyjrzeć.

Do opisu wykorzystam swoją pierwszą aplikację na Windows Phone. Trochę wstyd, ale dla dobra ludzkości trzeba się czasem trochę poświęcić. Przy okazji, jest ona dostępna na Baazar (nieoficjalny marketplace dla Windows Phone 7) – nazywa się CompactCal

Po uruchominiu NDepend można załadować plik solucji, którą chcemy poddać analizie. Następnie zostanie wyświetlona lista assemblies, które zostaną przeanalizowane:

Jak widać może się okazać, że czegoś będzie brakować, wtedy można dodać ręcznie brakujące pliki (np. używając drag’n’drop) walnąć OK. Warto zwrócić uwagę z której konfiguracji będą brane: debug czy release.

Czary mary, czekamy chwilę i wybieram opcje Close dialog – chce wszystko sam zobaczyć.
Pierwsze ciary na plecach, bo widzę bałagan w kodzie. Wszytko przez diagram zależności klas, u mnie wygląda on tak:

(Trochę się obrazek rozjechał)
Ci z nas, którzy posiadają Visual Studio wyższą niż expres (i chyba pro też), mogą znać już taki obrazek. Podobny widok można utworzyć w MVSC z menu Architecture -> Generate Dependency Graph -> By Assembly.
Ogólnie rzecz ujmując widać na nim, co od czego zależy i jak bardzo, im grubsza kreska tym więcej zależności w kodzie. Może być taka sytuacja że już tutaj zauważymy zależności których
nie powinno być. Może z jakiegoś powodu nasz View sięga bezpośrednio
do serwisów z danymi, a miał to robić tylko ViewModel. Po rozwiązaniu takich problemów, ja najczęściej usuwam  zależności od systemowy plików, tak jest dla mniej przejrzyściej.
Niestety ND (żeby nie pisać ciągle całej nazwy) nie potrafi sobie poradzić z ułożeniem kwadracików tak, aby linie się nigdzie nie przecinały. Nad czytelnością trzeba diagramu trzeba popracować samodzielnie. Nie wiem czemu, ale lubię właśnie w ten sposób mieć ułożone wszelkie diagramy.
Kolejnym innym widokiem zależności jest Matrix view, jest czytelniejszy niż diagram powyżej, w przypadkach gdy jest bardzo dużo obiektów do analizy.

U mnie tego nie widać, ale gdy pojawią się cyferki na czarnym tle, oznaczać to będzie zależności cykliczne. Choć muszę się przyznać, że gdy po raz pierwszy uruchomiłem ND na tym projekcie pewnie znalazło by się kilka czarnych miejsc. Na szczęście od tamtego czasu zdążyłem poprawić kod, a ten wpis powstaje dużo później. Widać na nim dokładnie zależności modułów, możemy badać zależność na podstawie ilości wykorzystywanych metod, pól, namespaces, typów zmiennych, i jeszcze kilku innych. ND potrafi także wykryć zależności nie bezpośrednie.
Po kliknięciu na jedno ze skrzyżowań, zobaczymy jeszcze dokładniejszy diagram tego, gdzie i jak są wykorzystywane te zależności, np. ViewModel vs. Helpers:

Do tego można wygenerować ciekawszy graph (Export Matrix Code Elements to Graph):

Co w wyniku da coś takiego:

W tym przypadku diagram zależności jest czytelny (linie się nigdzie nie przecinają).

To dopiero początek, jeśli już pogodziliśmy się ze skalą zależności w naszym kodzie warto przejść dalej i zobaczyć jakie reguły złamaliśmy oraz gdzie. ND dostarcza ponad 80 zdefiniowanych reguł. Możemy samodzielnie je modyfikować, dodawać nowe oraz usuwać te z nich , które naszym lub architekta odpowiedzialnego za projekt są z jakiegoś powodu nie potrzebne.

Tak bardzo źle nie jest, brak czerwonych kółeczek.

Jak widać powyżej istnieje kilka różnych grup zasad, z których część została w brzydki sposób naruszona, a część jest akceptowalna. Zobaczmy co zrobiłem źle, sprawdźmy Code Quality (dwuklik i widać szczegóły):

Każda grupa składa się znowu z kilku mniejszych reguł, tutaj jak widać mam najwyraźniej problem ze zbyt dużymi klasami i metodami. Brakiem komentarzy się nie przejmuje. Mój kod komentuje się sam – tak go wytresowałem.

Ważne jest to że parametry definiujące te reguły możemy samodzielnie zmieniać. Dla przykładu domyślne aby metoda została oznaczona za posiadającą zbyt duża ilość parametrów,  musi posiadać ich więcej niż pięć:

Metody zbyt duże muszą mieć więcej niż 30 linii kodu lub więcej niż 200 instrukcji IL.

Gdy już zdecydujemy się obejrzeć listę przewinień służy do tego osobny panel, ja sprawdzę którą z metod tak strasznie spasłem kodem:

Ja mam dwa takie przypadki, gdzie ten drugi jest bliski wartości granicznej. Aby obejrzeć kod wystarczy dwuklik na wybranym przypadku. W wersji darmowej trzeba niestety ręcznie znaleźć kod w MSVC.

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: Consolas, “Courier New”, Courier, Monospace;
background-color: #ffffff;
/*white-space: pre;*/
}

.csharpcode pre { margin: 0em; }

.csharpcode .rem { color: #008000; }

.csharpcode .kwrd { color: #0000ff; }

.csharpcode .str { color: #a31515; }

.csharpcode .op { color: #0000c0; }

.csharpcode .preproc { color: #cc6633; }

.csharpcode .asp { background-color: #ffff00; }

.csharpcode .html { color: #800000; }

.csharpcode .attr { color: #ff0000; }

.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}

.csharpcode .lnum { color: #606060; }

   1:  public static WriteableBitmap GenerateBitmapImage(string aHeading, IEnumerable<string> aItems)
   2:  {
   3:      WriteableBitmap wbm = null;
   4:      StackPanel sp = new StackPanel();
   5:      sp.Margin = new Thickness { Left = 6, Bottom = 0, Right = 6, Top = 0 };
   6:      sp.Height = 173;
   7:      sp.Width = 173;
   8:      sp.Background = new SolidColorBrush(Colors.Transparent);
   9:   
  10:      if (!string.IsNullOrEmpty(aHeading))
  11:      {
  12:          TextBlock heading = new TextBlock();
  13:          heading.Style = (Style)Application.Current.Resources["PhoneTextTitle3Style"];
  14:   
  15:          heading.Text = aHeading;
  16:          heading.Height = 35;
  17:          heading.Width = 173;
  18:   
  19:          sp.Children.Add(heading);
  20:      }
  21:   
  22:      int maxitems = (string.IsNullOrEmpty(aHeading)) ? 5 : 6;
  23:      int c = 0;
  24:   
  25:      foreach (var item in aItems)
  26:      {
  27:          TextBlock tbAction = new TextBlock();
  28:          tbAction.Foreground = (SolidColorBrush)Application.Current.Resources["PhoneAccentBrush"];
  29:          tbAction.Text = item;
  30:          tbAction.Style = (Style)Application.Current.Resources["PhoneTextNormalStyle"];
  31:          tbAction.Margin = new Thickness(4, 0, 0, 0);
  32:          tbAction.Height = 27;
  33:          tbAction.Width = 173;
  34:          sp.Children.Add(tbAction);
  35:          if (c++ > maxitems)
  36:          {
  37:              break;
  38:          }
  39:      }
  40:   
  41:      //call measure, arrange and updatelayout to prepare for rendering
  42:      sp.Measure(new Size(173, 173));
  43:      sp.Arrange(new Rect(0, 0, 173, 173));
  44:      sp.UpdateLayout();
  45:   
  46:      wbm = new WriteableBitmap(173, 173);
  47:      wbm.Render(sp, null);
  48:      wbm.Invalidate();
  49:      return wbm;
  50:  }

Rzeczywiście całkiem sporo, kod z bloków IF oraz FOREACH można wyrzucić do osobnych metod, tak samo ostatnie linijki z kodem który wymusza render na bitmapie. Poprawię to później 😉
To tylko jeden z wielu przypadków, który jest możliwy do przeanalizowania w kodzie. Jak już napisałem ND domyślnie ma ich ponad 80. Na stronie domowej są przykłady jak pisać własne CQL (code query language) i analizować kod na inny sposób, np:

  • Ostrzegaj gdy code coverage poniżej n%
  • Nazwy interfejsów nie zaczynające się od litery I
  • Wykorzystanie wątków inaczej niż przez ThreadPool
  • Zmiany wartości zmiennych, bez wykorzystania mechanizmów synchronizacji
  • Zbyt długa lista typów dziedziczących po X

Oprócz tego co wymieniłem powyżej, generowany jest także dodatkowy raport podsumowujący cały projekt, wykresy, liczby, inne pierdółki, coś co menadżerowie i klienci lubią najbardziej.
Skupmy się na najważniejszej grupie, na programistach.Są tam także informacje, które nam także się przydadzą.
Dodatkowy wykres wyświetlający stopień abstrakcji oraz stabilność waszego kodu. Gdzie stabilność nie oznacza dobrego kodu, a raczej współpracę z innymi typami (wsparcie dla polimorfizmu). W zasadzie ciężko wytłumaczyć ten parametr. Scott Hanselman ma podobny wpis o ND, tam tłumaczy trochę lepiej ten wykres: post Scotta.
Teraz będzie siara, bo o ile jestem zwolennikiem abstrakcji, to w tym projekcie pojechałem bez niej:

Warto trzymać się zielonej strefy.
I tak Service oraz GeocodeService był już tworzony z myślą o testach czy zastosowaniem innego źródła danych, dlatego znajduje się wyżej jeśli chodzi o oś Y (abstrakcję), natomiast Model, Extension (tam są metody rozszerzające), Helpery, etc jest płaskie jak deska. Położenie na osi X działa w taki sposób: jeśli assembly jest nie rozszerzalne, brakuje mu/jej jakiejkolwiek wirtualności, a dodatkowo wiele innych typów od niej zależy tym bliżej strefy bólu (na lewo) będzie się znajdować. U mnie wygląda to tak, że kod nie jest abstrakcyjny (są momenty), jednak nie posiadam klas które są wykorzystywane przez wszystkie inne. Brak tutaj typowych “utilsów” czy klas statycznych, do których wszyscy sięgają. Może dzięki temu jestem z pięknej zielonej strefie szczęścia. Model mógłby dodać od siebie trochę abstrakcji (może ISP), mógłbym sprawdzić czy wszędzie gdzie jest on wykorzystywany jest to potrzebne, może rozbić część klas na trochę mniejsze. Natomiast patrząc na Service widać że zbliża się on do powoli do zbyt wielkiej abstrakcji, lub braku wykorzystania części jego funkcjonalności. Warto sprawdzić czy wszystkie jego metody są potrzebne, może da się część z nich tak zmienić, aby wykorzystywały jakiś wspólny kod.

Z dodatkowych w raporcie ND można zobaczyć ile jest w sumie klas, metod w klasach, właściwości w klasach, linii kodu w projekcie, klasach, metodach, wszystko to co wymieniłem można także badać pod względem ilości poleceń w IL.

Po co utrzymywać kod z którego nikt nie korzysta? W moim przypadku zostało kilka metod, które zostały domyślnie stworzone przez wizarda podczas tworzenia projektu na Windows Phone, np. cała seria ApplicationLaunching, ApplicationActivated, ApplicationDeactivated czy ApplicationClosing. z której nigdzie nie korzystam. Takie proste rzeczy, a czynią kod z którym się pracuje przyjemniejszym w utrzymaniu.

ND wspiera MSVC 2008, 2010 oraz 2012. Umożliwia badanie kodu prosto z menu kontekstowego w edytorze:
Raporty można zapisywać, a następnie porównywać czy zmiany wprowadzane idą ku lepszemu. Dzięki integracji z VS można także prosto edytować i uruchamiać zapytania CQL – prosto ze środowiska pracy.
Na krótkich filmikach widziałem także, że ND potrafi porównywać ze sobą poszczególne wersje aplikacji. Niestety nie wiem jak do tego dojść, podejrzewam, że trzeba pilnować numerów wersji w assembly.
Odpalany z linii poleceń powinien być prosty do integracji z system CI (w domu takiego czegoś nie posiadam) i generować odpowiednio konfigurowalne raporty – menadżerowie się ucieszą. Możliwość zdefiniowania własnych reguł przy pomocy CQL umożliwi generowanie ostrzeżeń podczas budowania kodu, który np. nie posiada testów.

Pisałem wcześniej o tym, że warto rozmawiać. Zadawać pytania i czytać kod nie tylko swój. Poprosić znajomego o sprawdzenie tego co stworzyliśmy. ND wydaje się być czymś co może ten proces częściowo zastąpić. Nie warto jednak od razu usuwać ludzi z listy kontaktów. Jasna sprawa, że dla mnie czy innego Kowalskiego (pozdrawiam Tomka jeśli to czyta) jest on raczej drogim narzędziem 299 euro, szczególnie gdy w domu piszemy kod do szuflady. Ale gdy zarabia się na oprogramowaniu to świetne rozwiązanie, senior czy inny architekt może na początku projektu ustalić pewne zasady, który kod musi spełniać i dopiero gdy czekin w repozytorium spełni je wszystkie, zostanie przesłany do osobistego review. Pozwali to zaoszczędzić wszystkim dużo czasu (czas to pieniądz) oraz pominąć głupie i często powtarzające się błędy, np. brak słowa sealed przy klasie nie przeznaczonej do dziedziczenia.

TL;DR; (podsumowanie)
NDepend to dobre narzędzie do statycznego sprawdzenia kodu. Szczególnie przydatne w komercyjnych projektach, pozwoli automatycznie pilnować porządku w kodzie, zapewni przestrzeganie przyjętych zasad w projekcie. Zadowoli menadżerów wymagających nudnej papierologii. Nawet jeśli piszesz do szuflady, to na koniec lub po zakończeniu projektu, wykorzystaj wersję 14 dniową i sprawdź swój kod. Może się okazać, że da się lepiej.
Jeśli miałbym narzekać, to mogliby dać wersję darmową do domowego użytku.

Jest także NDepened dla Javy oraz dla C++. Niestety nie wiem jak dobre/złe są.

Linki:
NDepend strona domowa: http://www.ndepend.com/Default.aspx
Cennik: http://www.ndepend.com/Purchase.aspx
Lista ficzerów, część z nich posiada filmiki. Zabawne jest to, że korzystają z syntezatora mowy: http://www.ndepend.com/Features.aspx

Jeśli macie pytania to proszę o kontakt, jeśli chcecie żebym opisał jakąś część funkcjonalności ND to piszcie. Jeśli chcecie abym sprawdził jakiś kod to piszcie.

Metody rozszerzające – testowanie i porządek w api.

~ Jarosław Stadnicki ~ 3 Comments

Jak każdemu porządnemu developerowi zdarza mi się czasem napisać testy. Jak każdemu porządnemu developerowi, czasem zdarza mi się wykorzystać mechanizm metod rozszerzających (jeśli nie wiesz o czym mówię sprawdź na msdn). Jak każdy prawdziwy developer, chciałem przetestować logikę, która była wykorzystywana w jednej z takich metod. W zasadzie to nie w samej metodzie, chciałem sprawdzić czy zostanie wywołana z wartościami, które są dla mnie ważne.
Zacznę od metod rozszerzających, a testowanie przyjdzie samo.

Tak wygląda interfejs udostępniony przez samą (bez metod rozszerzających) klasę List:

Aby przewinąć listę na sam dół wystarczą trzy wciśnięcia Page Down. Jak widać jedyny import, z którego korzystam to System.Collections.Generic, wymagany aby móc skorzystać z List. 

To się stanie gdy dodam System.Linq: (obrazek się troszkę nie mieści)

Pojawi się nowa funkcjonalność, zdefiniowana w System.Linq, która pozwala robić cuda z listą i innymi IEnumerable (jak również innymi obiektami). Po imporcie aby przewinąć listę metod, trzeba osiem razy walnąć w Page Down.

Co zrobić, aby lista nowych funkcjonalności nie zaśmiecała dostępnego api? Można to wszystko ukryć przy pomocy jednej klasy, która przekierowuje żądania dalej, do właściwej części, gdzie zdefiniowane będą rozszerzenia
Normalnie implementacja rozszerzeń może wyglądać jakoś tak:

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: Consolas, “Courier New”, Courier, Monospace;
background-color: #ffffff;
/*white-space: pre;*/
}

.csharpcode pre { margin: 0em; }

.csharpcode .rem { color: #008000; }

.csharpcode .kwrd { color: #0000ff; }

.csharpcode .str { color: #a31515; }

.csharpcode .op { color: #0000c0; }

.csharpcode .preproc { color: #cc6633; }

.csharpcode .asp { background-color: #ffff00; }

.csharpcode .html { color: #800000; }

.csharpcode .attr { color: #ff0000; }

.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}

.csharpcode .lnum { color: #606060; }

   1:  namespace ConsoleApplication
   2:  {
   3:   
   4:      class Program
   5:      {
   6:          static void Main(string[] args)
   7:          {
   8:              MyClass mc = new MyClass();
   9:          }
  10:      }
  11:   
  12:      public static class MyClassExtension
  13:      {
  14:          public static void Foo0(this MyClass target) { }
  15:          public static void Foo1(this MyClass target) { }
  16:          public static void Foo2(this MyClass target) { }
  17:          public static void Foo3(this MyClass target) { }
  18:          public static void Foo4(this MyClass target) { }
  19:          public static void Foo5(this MyClass target) { }
  20:          public static void Foo6(this MyClass target) { }
  21:          public static void Foo7(this MyClass target) { }
  22:          public static void Foo8(this MyClass target) { }
  23:          public static void Foo9(this MyClass target) { }
  24:      }
  25:   
  26:      public class MyClass
  27:      {
  28:      }
  29:  }

Po takiej implementacji otrzymujemy cztery metody podstawowe, oraz dodatkowy dziesięć nowych z rozszerzenia w MyClassExtension.

Można trochę to wszystko uprościć dodając odpowiednią warstwę abstrakcji (abstrakcja was uwolni, zapamiętajcie to). Opis poniżej:

   1:  namespace ConsoleApplication
   2:  {
   3:      using System;
   4:   
   5:      class Program
   6:      {
   7:          static void Main(string[] args)
   8:          {
   9:              MyClass mc = new MyClass();
  10:              mc.ExtensionService().Foo0();
  11:          }
  12:      }
  13:   
  14:      public static class MyClassExtension
  15:      {
  16:          public static Func<MyClass, IMyClassExtensionService> ExtensionFactory { get; set; }
  17:   
  18:          static MyClassExtension()
  19:          {
  20:              ExtensionFactory = target=> new MyClassExtensionReleaseVersion(target);
  21:          }
  22:   
  23:          public static IMyClassExtensionService ExtensionService(this MyClass target)
  24:          {
  25:              return ExtensionFactory(target);
  26:          }
  27:      }
  28:   
  29:      public interface IMyClassExtensionService
  30:      {
  31:          void Foo0();
  32:          void Foo1();
  33:          void Foo2();
  34:          void Foo3();
  35:          void Foo4();
  36:          void Foo5();
  37:          void Foo6();
  38:          void Foo7();
  39:          void Foo8();
  40:          void Foo9();
  41:      }
  42:   
  43:      public class MyClassExtensionReleaseVersion : IMyClassExtensionService
  44:      {
  45:          private MyClass myclass;
  46:   
  47:          public MyClassExtensionReleaseVersion(MyClass target)
  48:          {
  49:              this.myclass = target;
  50:          }
  51:   
  52:          public void Foo0() { }
  53:          public void Foo1() { }
  54:          public void Foo2() { }
  55:          public void Foo3() { }
  56:          public void Foo4() { }
  57:          public void Foo5() { }
  58:          public void Foo6() { }
  59:          public void Foo7() { }
  60:          public void Foo8() { }
  61:          public void Foo9() { }
  62:      }
  63:   
  64:      public class MyClass
  65:      {
  66:      }
  67:  }

Tak się to prezentuje teraz:

Zacznę od linijki 29 gdzie zdefiniowany został interfejs ze wszystkimi metodami, które mają działać jako rozszerzenie dla klasy MyClass. Linia 43 to implementacja tego interfejsu, warto zauważyć że klasa ta nie jest statyczna, oraz nie posiada statycznych pól, a metody nie przyjmują parametrów. W konstruktorze otrzymuje ona obiekt, na rzecz którego ma działać. Najlepsze zostawiam na koniec, linijka 14, klasa udostępniająca rozszerzenie dla MyClass. W ExtensionService (23) wykorzystywana jest właściwość ExtensionFactory, który jest zwyczajną metodą wytwórczą, zwracającą nowy obiekt MyClassExtensionReleaseVersion, do którego przesyła obiekt, na rzecz którego ma zostać wywołana metoda rozszerzająca. Mam nadzieję, że kod tłumaczy to prościej niż ja. Linia 10 to nowy sposób na wywołanie metod rozszerzających. 
Właściwość ExtensionFactory została zdefiniowana jako publiczna, co umożliwia jego zmianę w razie potrzeby testowania. Tak samo obiekt rozszerzający jest deklarowany poprzez interfejs, w związku z czym w testach można wykorzystać np. MyClassExtensionMockVersion i sprawdzać czy klasa zachowuje się tak jak tego oczekujemy.

Ja skorzystałem z tego rozwiązania podczas testowania nawigacji w projekcie, który korzysta z PRISMa, tam do zmiany widoków wykorzystywany jest interfejs IRegionManager i kilka metod rozszerzających ten interfejs. Chciałem sprawdzić, czy po wykonaniu operacji X jedna z moich klas zarząda zmiany widoku. Jedynym sposobem, na sprawdzenie parametrów przesłanych w query było stworzenie i podstawienie własnej implementacji metod rozszerzających. Na początku testów mam taki zapis:

   1:  Capture.Common.Prism.PrismExtensions.ServiceFactory = p => new NavigationServiceMock(p);

Tak wygląda mój lipny serwis, który działa zamiast tego z Prism:

   1:  public class NavigationServiceMock : INavigation
   2:  {
   3:      private IRegionManager p;
   4:   
   5:      public NavigationServiceMock(IRegionManager p)
   6:      {
   7:          this.p = p;
   8:      }
   9:   
  10:      public IRegionManager AddToRegion(string regionName, object view)
  11:      {
  12:          throw new NotImplementedException();
  13:      }
  14:   
  15:      public IRegionManager RegisterViewWithRegion(string regionName, Func<object> getContentDelegate)
  16:      {
  17:          throw new NotImplementedException();
  18:      }
  19:   
  20:      public IRegionManager RegisterViewWithRegion(string regionName, Type viewType)
  21:      {
  22:          throw new NotImplementedException();
  23:      }
  24:   
  25:      public void RequestNavigate(string regionName, string source)
  26:      {
  27:          throw new NotImplementedException();
  28:      }
  29:   
  30:      public void RequestNavigate(string regionName, Uri source)
  31:      {
  32:          LoadTradeViewModelTest.NavigationServiceMock_RequestedNavigatedTargetRegionName = regionName;
  33:          LoadTradeViewModelTest.NavigationServiceMock_ReqestedNavigatedTargetUri = source.OriginalString;
  34:      }
  35:   
  36:      public void RequestNavigate(string regionName, string source, Action<NavigationResult> navigationCallback)
  37:      {
  38:          throw new NotImplementedException();
  39:      }
  40:   
  41:      public void RequestNavigate(string regionName, Uri source, Action<NavigationResult> navigationCallback)
  42:      {
  43:          throw new NotImplementedException();
  44:      }
  45:  }

Najważniejsze w tym wszystkim to RequestNavigate (30) gdzie zapisuje żądany region i uri. Później w teście porównuje czy są takie jak oczekiwałem. Wszystkie NotImplementedException są nie używane w testach, dlatego też mogły pozostać w takiej domyślnie oferowanej przez VS formie.
Normalna implementacja przekazuje wszystkie parametry do oryginalnej implementacji.

Pojawia się pewien problem, przy próbie stworzenie podobnego rozwiązania dla klas generycznych. Ten problem to kompilator, który cały czas twierdzi że metody rozszerzające muszą być w klasach statycznych, nie generycznych. Same metody mogą być generyczne. Aby to obejść na szybko wymyśliłem coś takiego 

   1:  namespace ConsoleApplication
   2:  {
   3:      using System;
   4:      using System.Collections.Generic;
   5:   
   6:      class Program
   7:      {
   8:          static void Main(string[] args)
   9:          {
  10:              List<int> l = new List<int>();
  11:              l.GetExtension().Foo1();
  12:          }
  13:      }
  14:   
  15:      public static class ExtensionsFactory<T>
  16:      {
  17:          public static Func<List<T>, IListExtensionService> Factory { get; set; }
  18:      }
  19:   
  20:      public static class ListExtension
  21:      {
  22:          public static IListExtensionService GetExtension<T>(this List<T> target)
  23:          {
  24:              if (ExtensionsFactory<T>.Factory == null)
  25:              {
  26:                  ExtensionsFactory<T>.Factory = o => new ListExtensionSerivce<T>(o);
  27:              }
  28:   
  29:              return ExtensionsFactory<T>.Factory(target);
  30:          }
  31:      }
  32:   
  33:      public interface IListExtensionService
  34:      {
  35:          void Foo1();
  36:      }
  37:   
  38:      public class ListExtensionSerivce<T> : IListExtensionService
  39:      {
  40:          private List<T> list;
  41:   
  42:          public ListExtensionSerivce(List<T> target)
  43:          {
  44:              this.list = target;
  45:          }
  46:   
  47:          public void Foo1()
  48:          {
  49:              Console.WriteLine("foo and the list");
  50:          }
  51:      }
  52:  }

Cały trik w tym przypadku, to przeniesienie odpowiedzialności na wytwarzanie obiektów z ListExtension do ExtensionsFactory. A podczas wywołania metody, należny się upewnić że fabryka już istnieje.

Myślę że wystarczy mojego wymądrzania się na dziś. Podoba się? Nie podoba się? Macie inne sposoby? Pytania? Uwagi? Cokolwiek?

ps
Mam nadzieję, że więcej wyjaśniłem niż zakręciłem.
ps2
Jak już wszystko napiszę, to czytam czy jest ok, a potem i tak mam lekkiego stresa, że coś głupiego napisałem.