How should we treat virtual methods exposed in APIs (Part 2)

In postul precedent am descutat despre o problema care poate sa apara cand expunem intr-un API metode virtuale, care sunt apoi suprascrise de catre un alt dezvoltator. Iar o versiune ulterioara a API schimba comportamentul aplicatiei in asa fel incat suntem obligati sa schimbam codul care foloseste API expus.
Mai jos gasiti o posibila solutie la aceasta problema.

public abstract class FooBase
{
    private void DoAction()
     {
          // Custom code that can be executed by our method.           
          DoActionCore();           
          // More custom code that can be executed by our method.       
     }   

     public virtual void DoActionCore()   
     {              
          // Some action
     }
}

public class MyCustomFoo : FooBase
{   
     public override void DoActionCore()   
     {       
          // My custom code of MyCustomFoo that will be       
          // executed by DoAction method from base class.   
     }
}

O solutie de acest gen o sa functioneze, doar daca cel care expune API o sa o foloseasca de la prima versiune.
O alta varianta este ca metode DoActionCore sa fie declarata ca si abstracta, in cazul in care vrem sa obligam dezvoltatorul sa defineasca un comportament custom.

Read More

How should we treat virtual methods exposed in APIs

Cu cateva zile in urma mi s-a cerut sa investighez de ce nu functioneaza o aplicatie asa cum trebuia in urma unui upgrade de framework, iar cand am gasit cauza problemei am zis ca trebuie sa va zic si voua.
Un mic framework care era folosit definea o clasa de baza abstracta, care la randul ei continea cateva metode virtuale.

public abstract class FooBase
{
    public virtual void DoAction1()
    {
        ...
    }
    ...
}

Implementarea care era facuta in sismul nostru asta in felul urmator:

public class MyCustomFoo : FooBase
{
    ...
    public override void DoAction1()
    {
         // Some custom action
         ... 
    }
}

Problema la MyCustomFoo este ca metoda DoAction1() nu apeleaza metoda din clasa de baza. Asta nu ar fi nici o problema cat timp cel care a scris acest cod implementeaza aceasta functionalitate. Pe vechia versiune de framework, acest lucru era in regula, dar noua versiune schimba usor o functionalitate si are nevoie neaparat ca metoda din clasa de baza sa fie apelata.
Intrebarea care a aparut aici in cazul meu a fost: Cine este de vina?
Din unele puncte de vedere as spune ca dezvoltatorul care a implementat clasa MyCustomFoo. Acesta trebuie sa se asigure ca apeleaza si metoda din clasa de baza, pastrand vechia functionalitate.
Totodata metoda era marcata ca virtual, cea ce inseamna ca cel care marcato ca virtual permite persoanei care face ovveride sa schimbe modul de implementare a respectivei functionalitati. Dar sa nu uitam, ca in momentul in care face ovveride nu trebuie sa alterezi vechiul comportament.
Noua versiune de framework trebuia si i-a modificata in asa fel incat sa nu se altereze functionalitatea in nici un fel, dar unele modificari pot sa duca la unele schimbari si in clasele virtuale.
In acest caz noua versiune trebuie sa fie insotita si de un document cu modificarile la API care au fost facute.
Voi ce parere aveti? Intr-un caz de acest gen cine poarta vina este raspuzator pentru aceasta problema?

Partea a doua din aceasta discutie: http://vunvulearadu.blogspot.ro/2012/06/how-should-we-treat-virtual-methods.html.

Read More

Can we mock an extension method?

Pentru teste mai mult ca sigur ati folosit un framework petru a face mock pe diferite obiecte. In general am folosit Moq pentru a putea face mock la date. Este destul de usor de folosit, mai jos puteti sa gasiti un exemplu:

Mock<IService> serviceMock = new Mock<IService>();
serviceMock
    .Setup(x=>x.Call(It.IsAny<string>))
    .Returns(()=> new Result());

Mai sus am creat un mock pentru IService, iar in momentul in care se apeleaza metoda Call cu orice parametru de tip string, se returneaza un nou obiect de tip Result.
Nimic deosebit pana acuma. Dar ce se intampla daca vrem sa facem mock la un extension method. Vestea proasta este ca nu se poate face. Majoritatea framework-urilor pentru mock-ing nu suporta aceasta functionalitate.
Cea mai buna solutie este sa refactorizam codul daca putem. Dar exista cazuri cand acest lucru nu il putem face sau extension method nu este declarat de noi si vine dintr-un assembly exterior.
O solutie comuna, care poate sa fie folosita atat pentru aplicatiile .NET classic, Silverlight, WP7, ... este sa injectam actiunea care apeleaza metoda noastra. De exemplu putem sa extragem intr-un Action actiunea care apeleaza extension method, iar aceasta sa fie injectata prin contructor folosind un factory de exemplu. O alta varianta este sa facem un wrapper peste clasa noastra.
Urmatoarea solutie nu functioneaza pe Silverlight din pacate. Ar fi fost nice sa fie suportatat macar in versiunea 5, dar nici o sansa. Solutie se refera la folosirea Microsoft Moles. Prin intermediul acestui framework putem sa inlocuim orice clasa, metoda cu un mole care sa faca ce vrem noi. Un mole, intercepteaza apelul spre o anumita metoda si se poate executa orice alt cod. Putem sa facem mole la orice fel de metoda, atat statica cat si extension method.

Read More

Cum sa salvezi un stream direct intr-un fisier

Cred ca este a 2-a oara când întâlnesc aceasta cerința in decurs de câteva săptămâni.
Se da un stream și o locație unde trebuie salvat, se cere să se salveze conținutul la stream in locația data. Din păcate API-ul de .NET nu ne permite să facem acest lucru doar dintr-un apel.
O soluție propusa este următoarea:

        /// <summary>
       /// Save the stream to the given location.
       /// </summary>
       /// <param name="stream">The stream.</param>
       /// <param name="filePath">The file path where is saved.</param>
       /// <param name="blockSize">The size of the buffer(in kB)</param>
       public static void SaveStream(this Stream stream,String filePath,SeekOrigin seekOrigin=SeekOrigin.Begin,int blockSize=1)
       {
           //Set the poinder to the begin of the stream.
           if(stream.CanSeek && seekOrigin==SeekOrigin.Begin)
           {
               stream.Seek(0, SeekOrigin.Begin);
           }

           //Removed the existing file.
           if (File.Exists(CommandLineArguments.Instance.File))
           {
               File.Delete(CommandLineArguments.Instance.File);
           }

           //Save the stream to the given location.
           using (var streamWrite = File.Create(CommandLineArguments.Instance.File))
           {
               byte[] buffer = new byte[1024*blockSize];
               int read;

               while ((read = stream.Read(buffer, 0, buffer.Length)) > 0)
               {
                   streamWrite.Write(buffer, 0, read);
               }
           }
       }

Iar un exemplu de utilizare:

Stream stream=...;
stream.Save("d:/a.txt");

In funcție de necesitați acest exemplu se poate extinde. Din păcate nu putem să facem un extension method pe File deoarece este o clasa statica.

Read More