venerdì 17 giugno 2011

State Object ?

In molti casi salta fuori questo spelndido concetto che però sembra applicabile a pochi contesti, anche se scondo me si può estendere/astrarre.

Il caso pratico è di mantenere lo stato di un oggetto in modo da poter accedere al suo contenuto di modificarlo e di renderlo fruibile a vari oggetti.

Questo deve in ogni modo essere "immutabile" anche se vedremo che un senso "molto" lato del concetto stesso.

class DataAnchor
{
private string _entryValue = "";
private int _entryStatus = 0;

public string entryValue
{
get { return _entryValue; }
set { _entryValue = value; }
}

public int entryStatus
{
get { return _entryStatus; }
set { _entryStatus = value; }
}
}

class StateObject
{
public static DataAnchor Anchor = new DataAnchor();
}



Letto il codice non è difficile comprendere che lo StateObject è una classe che banalmente espone come propietà statica l'oggetto che ci servirà.

Ora parlando per astrazione è possibile contestualizzare quest'esempio

class useState
{
public useState()
{
StateObject.Anchor.entryValue = "Inzio";
}

public void doSample()
{
Thread t1 = new Thread(StepA);
Thread t2 = new Thread(StepB);

t1.Start();

while (StateObject.Anchor.entryStatus != 1)
{
t2.Start();
break;
}
}

private void StepA()
{
StateObject.Anchor.entryValue = "StepA";
StateObject.Anchor.entryStatus = 1;
Console.WriteLine("t1..done");
}

private void StepB()
{
StateObject.Anchor.entryValue = "StepB";
StateObject.Anchor.entryStatus = 2;
Console.WriteLine("t2..done");
}
}


Benchè banale ... ( e ammetto anche fin troppo ) rende chiaro il concetto di stateObject.
In questo caso il processo esegue due tread che mutano lo stato del nostro state object e qualora i thread fossero n è possibile applicare una logica di concorrenzialità in modo che il primo dei due che porta l'oggetto a uno stato differente, può invocare il terzo thread..

Nessun commento: