Communicatie in projecten

Het is altijd leuk om een project te doen, we doen het allemaal goed en onze projecten lopen altijd gesmeerd…

Eén van de dingen die ikzelf tegenkom in de projecten die uitgevoerd worden is dat de communicatiestromen niet altijd helder zijn. Anders verwoord kun je het ook noemen dat niet altijd duidelijk is welk persoon welke rol in het project heeft.

Zorg ervoor dat je duidelijk krijgt welke rol je in het team speelt, ben je ontwikkelaar, blijf dat dan ook; speel geen projectleider, Scrum Master en maak dat ook duidelijk aan je klanten. En geef de juiste rol ook de juiste taken… Zorg er dus voor dat je niet op de plaats van de Scrum Master gaat zitten en daarbij denkt dat je de klant helpt…

stick to your assignment and complete it...

Eventbus / Messagbus

Gisteren een eventbus geimplementeerd voor het doorgeven van een event vanuit verschillende controllers (mvc) zodat er niet gerefreshd zou worden. De messagebus heeft een generic event waar je op aan kunt haken en een sentmessage die je kunt aanroepen zodat het event zal afgaan. het object wat je doorgeeft is de generic. Erg handig, maar nu vroeg ik mezelf af wat het voordeel is ten opzichte van een interface implementatie op de controllers waarin de specifieke events en methods zitten.

Wanneer gebruik je nu welke??
Persoonlijk vind ik dat een interface duidelijk aangeeft dat je de events gebruikt en elkaar informeert, bij de messagebus / eventbus ben je meer loosely coupled…
Wat vinden jullie?

nog meer dynamics

4.0 is overgoten met dynamische oplossingen, is dat het einde van het gebruik van het dure reflection?

In de vorige post schreef ik over het dynamic keyword en het gebruik van optional parameters om late binding te kunnen werken met bijvoorbeeld office.

In sommige applicaties gebruiken we reflection om runtime de objecten te kunnen uitlezen en gebruiken. In 4.0 is het gebruik van DLR aanwezig en zijn er classes gemaakt in de System.Dynamic namespace waarmee je runtime eigenschappen en methoden kunt toevoegen.
Je hebt twee classes die je daarvoor kunt gebruiken; ExpandoObject en DynamicObject.
Het ExpandoObject is sealed en kun je gebruiken door daar je eigen properties aan te maken, bijvoorbeeld

dynamic persoon = new ExpandoObject();
persoon.Achternaam = "Vos";

het DynamicObject is niet sealed en kun je gebruiken om je eigen dynamische oplossing te schrijven. Je kunt hier de methoden TrySetMember en TryGetMember
overriden zodat je je eigen werking kunt beinvloeden.

meer hierover kun je terugvinden op:
http://msdn.microsoft.com/en-us/library/system.dynamic.dynamicobject.aspx

http://blogs.msdn.com/b/csharpfaq/archive/2009/10/01/dynamic-in-c-4-0-introducing-the-expandoobject.aspx
http://msdn.microsoft.com/en-us/library/system.dynamic.expandoobject.aspx

C# late binding

In vbscript of vb6 en vba kon je altijd CreateObject("...") gebruiken om zo runtime en versie onafhankelijk object te creeren via ProgID om een IDispatch object terug te geven.

In C# 4.0 is dat nu ook mogelijk via het keyword Dynamic. Eindelijk, of juist niet??

Het werken met bijvoorbeeld Microsoft Office wordt in ieder geval veel gemakkelijker dan het was in framework 3.0.

Bij het gebruik van dynamic heb je geen intellisence meer in Visual Studio, wat logisch is. Je hebt ook geen kennis van het object designtime, alleen runtime.

In 3.0 moest je bijv. reflection gebruiken om de methods goed te kunnen aanroepen, nu checkt de compiler niets meer en werk je net zoals je gewend was in scripting...

Is dit een verbetering of niet? Ik weet het niet, maar het scheelt een hoop code in combinatie met optional parameters als je tegen office kletst...

Visual Studio 2010 Extension Manager

Gisteren is de Visual Studio Pro Power Tools beschikbaar gekomen.

In VS2010 heb je nu een Extension Manager zitten, hierin zijn handige tools beschikbaar gekomen waarmee je rechtstreeks uitkomt in de visual studio gallery.
Via Tools -> Extension manager kun je de optie gebruiken
Er zijn handige tools gratis beschikbaar!

Covariance en Contravariance - Part 1

Covariance en Contravariance zijn nieuwe begrippen van .net 4.0 die wellicht vaag overkomen, maar we gebruiken het eigenlijk altijd al in object orientatie; genaamd polymorphisme.

Voorbeeld:
class Person {
string Name {get;set;}
}
class Employee : Person {
string EmployeeNr {get;set;}
}

class F
{
public void Foo(Person p)
{
Console.WriteLine(p.Name);
}
public void Foo (Person[] p)
{
foreach (Person item in p){
....
}
}

}

//implementatie
new F().Foo(new Employee());


Wat je definieert is een methode wat een baseclass als parameter ontvangt en in je implementatie geef je een derived class door.
Dit heet Contravariance

Dit werkt ook gewoon voor de array implementatie, maar tot en met versie 3.5 was dit niet mogelijk voor Generics.

De volgende method compileerde niet als je daar een lijst met Employees aan doorgeeft
public void Foo (IEnumerable<Person> p)
{
foreach (var item in p){
....
}
}

Het voorbeeld met de method Foo wordt aangeduid als Contravariance.
Contravariance werkt met inkomende inheritance van de generic types, dit wordt nog duidelijker als je met delegates gaat werken.

Indien je een delegate wilt definieren welke het polymorphisme ondersteund dan schrijf je het volgende:

public void SetNameDelegate<in T, in T2>(T person, T2 name);
Je kunt deze nu aanroepen door:
SetNameDelegate setName = (p,n) => { p.Name = n; };
SetNameDelegate setNameEmp = setName;
Door het gebruik van hetkeyword IN geef je de compiler aan dat deze er vanuit kan gaan dat het juiste type wordt doorgegeven om mee te werken.

Ik hoop dat het zo een stukje duidelijker is geworden voor eenieder.
Eerdaag zal ik een stukje schrijven over Covariance

Optional en named parameters

Nieuw in C# 4.0 is optional en named parameters.

Net zoals we kennen in het oude vb of vba kunnen we tegenwoordig gebruik maken van optionele parameters.

Voorbeeld:

public class Person
{
public string Achternaam{ get;set; }
public string Voornaam {get;set;}
public string Voorvoegsel {get;set;}
}

public void SetName(string voornaam, string achternaam = "Vos")
{
Voornaam = voornaam;
Achternaam = achternaam;
}

We kunnen nu de methode SetName als volgt aanroepen:

SetName("Patrick", "Vos") of SetName("Patrick");

Named Parameters

Tevens kun je met named parameters aangeven welke variabele je wilt vullen, voorbeeld:

SetName(voornaam: "patrick", achternaam: "vos") of

SetName(achternaam: "vos", voornaam: "patrick")

Tevens kun je nu overloads maken die met optionele parameters eigenlijk dezelfde signature krijgen, maar met named arguments/parameters wel kunnen worden uitgevoerd:

public void SetName(string achternaam, string voornaam = "Patrick",
string voorvoegsel = "van")
{
Achternaam = achternaam;
Voornaam = voornaam;
Voorvoegsel = voorvoegsel;
}

Je kunt nu de met SetName alleen nog maar als volgt aanroepen:

SetName(voornaam: "Patrick"); of
SetName(achternaam: "Vos");
Het eerste voorbeeld SetName("Patrick") werkt nu dus niet meer!!