VM Depot - Stepping into a new era

From last year, Windows Azure started to support any kind of system on Virtual Machines. We can install a Linux operating system on them without any kind of problem. Also we have some images created by default, with different operating system, that can be used by anybody.
This year we have a new feature related to these images.  Windows Azure offers VM Depot. This is a place where anybody can upload his image of operation system and share with others. For example we can create and share with others an image of Ubuntu that is preconfigured to run different application like Redmine, Moodle,  Glitorious and so on.
A nice feature of this system is the rating and feedback mechanism. Each user can rate an image and give feedback. In this way people can select more easily an image for themselves. Not only this, but you can take an image, change it and share it again with others.
When you want to deploy an image of a VM machine from Windows Azure, VM Depot will generate the command line that you need to run on Cloud to install the specific image on your virtual image. Publishing your machine is simpler than deploying it. You need to set a name, description and a URL path where the VHD is published. 
You don’t need to have a Windows Azure account to be able to navigate, get the deployments script or publish a new virtual machine.
The real value of this service is for the companies that have a product that can be run on cloud also. Image that you are a software company that has a great product for online payment. Your product is developed in C++ and runs on Ubuntu. You will be able to publish an image of your VM machine for all your customers very easily. In this way your customer will have images of your server pre-configured.
Using this new service we can share and deploy images for Windows Azure very easily.

Read More

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

Field like events and polymorphic invocation

Ce vi se pare gresit in codul de mai jos:

public class Base
{
    public virtual event EventHandler EventOne;
}
public class Derived : Base
{
    public override event EventHandler EventOne;
    public void DoAction()
    {
        ...
        EventOne(this, args);
    }
}

In clasa de baza avem un eveniment la care se poate face override in orice clasa derivata. Desi la prima vedere totul pare sa fie in ordine daca ne uitam mai atent, putem sa observam o problema care poate sa apara din cauza la override.
EventOne o sa existe in doua locatii diferite, atat in clasa de baza cat si in clasa derivata. Din aceasta cauza o sa fie momente cand EventOne din clasa de baza nu o sa fie niciodata instantiat.
Din aceasta cauza, in cazul in care evenimentul este apelat din clasa de baza ne putem trezi cu un comportament ciudat, precum NullReferenceException sau sa se execute cod la aruncarea unui eveniment pe care noi nu ne-am astepta sa se execute.
Ce putem sa facem ca sa rezolvam aceasta problema?
Avem la indemana doua solutii. Prima varianta este sa eliminam virtual si override. O sa fie nevoie sa ne declaram o metode de tip "event-firing" in clasa de baza. Aceasta metoda o sa fie adaugata in clasa de baza si tot ce va face este sa arunce evenimentul nostru. In clasa derivata nu se va folosii direct evenimentul ci se va apela metoda pe care noi am declarato in clasa de baza. Iar aceata la randul ei o sa arunce evenimentul. Mai jos puteti sa gasiti implementarea propusa:

public class Base
{
public event EventHandler EventOne;
public void FireEventOne(object sender, EventArgs args)
    {
        if (EventOne != null)
        {
            EventOne(sender, args);
        }
    }
}
public class Derived
{
    public void DoAction()
    {
        ...
        FireEventOne(this, args);
    }
}

In varianta data mai sus, clasa derivata nu mai poate sa faca override la eveniment, aceasta putand doar sa se inscrie la acest eveniment. Field-ul EventOne nu o sa mai fie duplicat in clasa de baza. Prim aceasta metoda am eliminat orice comportament ciudat care ar fi putut sa apara.
Daca avem nevoie sa facem override, atunci va recomand sa mergeti pe varianta in care in clasa de baza evenimentul sa fie declarat ca si abstract( nu consider aceasta variata ca fiind cea mai sanatoasa).

public class Base
{
  public abstract event EventHandler EventOne;
}

Va recomand sa va ganditi de doua ori daca chiar aveti nevoie de un eveniment abstract. S-ar putea ca design-ul pe care l-ati ales sa nu fie cel mai bun.

Read More

Metoda marcata cu abstract si override

O metoda sau o propietate poate sa fie marcata ca abstracta cand aceasta nu contine si implementarea.
O metoda sau o propietate poate sa fie marcata ca override cand vrem sa modificam implementarea si sa oferim o noua implementare pentru un menbru mostenit din clasa de baza.
Pana aici nimic deosebit, OOP pur. Oare putem sa avem o metoda care sa fie marcata atat abstracta cat si override? Raspunsul este DA. Desi pare ciudat, putem sa marcam o metoda cu aceste doua atribute:

public void abstract override DoWork();

Cand putem sa avem acest caz?
Cand avem o clasa abstracta care contine o metoda virtuala.

public abstract Actiune
{
   public virtual void DoWork()
   {  
       Console.Write("Actiune1.DoWork");
   }
}

Aceasta clasa poate sa fie mostenita de o alta clasa care sa ofere o alta implementare de baza la metoda DoWork.

public abstract Actiune2 : Actiune
{
   public abstract override void DoWork();
}

Orice clasa ce va implementa clasa abstracta Actiune2 o sa fie obligata sa ofere o implementare la metoda DoWork(), chiar daca Actiune2 mosteneste din clasa abstracta Actiune1 care ofera o implementare pentru metoda noastra.

Read More