Jak funguje GraphViz

Samotný GraphViz (tedy nikoliv Graphviz4Net) se používá zhruba následovně. Stačí vytvořit textovou reprezentaci grafu, který chceme vizualizovat. K tomuto účelu slouží jazyk DOT.

digraph G {
	node [shape=rect];
	node1 [label="A", width=2, height=1];
	node2 [label="B"];
	node3; node5;
	node1 -> node2 [label="Edge from A to B"];
	node3 -> node1; node3 -> node5;
	node1 -> node5; node5 -> node2;
}

Potom stačí použít utilitu dot, která je součástí GraphViz.

dot -Tpng graph.gv > graph.png

A výsledný obrázek vypadá následovně:

Graphviz4Net

Graphviz4Net umožňuje použít GraphViz pro vizualizaci grafů ve WPF. Uzly grafu mohou být libovolné WPF komponenty, i všechny další prvky grafu je možné customizovat. Graphviz4Net podporuje pod-grafy (ohraničené komponenty v grafu), hrany mezi pod-grafy, popisky u hran, popisky u konců hran a různé tvary konců hran. Více informací o Graphviz4Net, včetně příkladu použití, lze získat na domácí stránce projektu.

Methods dispatching

Nejprve zavedeme jednoduchou terminologii — statický typ objektu a aktuální typ objektu. V následující ukázce je Stream statickým typem objektu „obj“ a FileStream je jeho aktuálním typem. Aktuálním typem objektu „obj“ může být kterýkoliv potomek abstraktní třídy Stream.

Stream obj = new FileStream("foo.txt", FileMode.Create);
// ... změníme aktuální typ:
obj = new MemoryStream(/* ... */);

Začneme menším kvízem: co bude výstupem následujícího program (nebo-li, která verze metody Foo se zavolá)?

public class Program {
  public static void Foo(object o) {
    Console.WriteLine("Foo:object");
  }

  public static void Foo(string str) {
    Console.WriteLine("Foo:string");
  }

  public static void Main(string[] args) {
    object obj = new string("ahoj svete");
    Foo(obj);
  }
}

Správná odpověď je „Foo:object“, protože kompilátor vybírá mezi Foo(string) a Foo(object) už během kompilace na základě statického typu parametru „obj“ a tím je object, ne string. Jediný případ (zatím neuvažujeme Reflection), kdy je skutečně zavolaná metoda vybrána až za běhu, jsou virtuální metody jako u následujícího příkladu, jehož výstupem je „Foo:Bar“.

public class Program {
  class Baz {
    public virtual void Foo() {
      Console.WriteLine("Foo:Baz");
    }
  }

  class Bar : Baz {
    public override void Foo() {
      Console.WriteLine("Foo:Bar");
    }
  }

  public static void Main(string[] args) {
    Baz b = new Bar();
    b.Foo();
  }
}

Zde je metoda Foo vybraná na základě aktuálního typu objektu b, tedy je správně vybraná metoda Foo ze třídy Bar. Proč tomu tak je a jak to celé funguje? C# kód se překládá do mezikódu (MSIL) a tento mezikód potom překládá Just-in-time kompilátor přímo do strojového kódu. .NET mezikód je takový trochu „higher-level assembler“ a poskytuje několik instrukcí pro volání metod. Nejdůležitější jsou .call a .callvirt. Čím se tyto dvě instrukce liší? První z nich, .call, překládá Just-in-time kompilátor čistě jako volání konkrétní metody pomocí její pevně zadané adresy. Na druhou stranu instrukce .callvirt je přeložena do strojového kódu, který adresu volané metody vybere podle tabulky virtuálních metod. Důsledkem je, že instrukce .callvirt je pomalejší než .call, ale poskytuje lepší flexibilitu.

Tomu jak se vybírá metoda, která je nakonec skutečně zavolaná, se říká dispatching od anglického dispatch (vypravit, expedovat). C# podporuje takzvaný single dispatch, kdy je skutečná metoda vybraná na základě aktuálního typu objektu, na kterém je zavolaná. Některé jazyky, především dynamické, podporují takzvaný multiple dispatch, kdy je skutečně zavolaná metoda vybraná na základě aktuálních typů všech jejích argumentů i objektu, na kterém je zavolaná (pokud je instanční). Kód ekvivalentní úvodní ukázce by v takovém jazyce po spuštění vypsal „Foo:string“.

Multiple dispatch lze použít i v C# pomocí klíčového slova dynamic. Následující kód vypíše „Foo:string“. Důležité je přetypování parametru na „dynamic“.

public class Program {
  public static void Foo(object o) {
    Console.WriteLine("Foo:object");
  }

  public static void Foo(string str) {
    Console.WriteLine("Foo:string");
  }

  public static void Main(string[] args) {
    object obj = new string("ahoj svete");
    Foo((dynamic)obj);
  }
}

K čemu se hodí multiple dispatch?

Uvažme následující hierarchii tříd

public class Employee {
  double Salary { get; set; }
}

public class Worker : Employee {}
public class Manager : Employee {}

a nyní následující situaci: máme instanci kolekce objektů typu Employee a chceme všem managerům (třída Manager) zvýšit plat o 1000 a pracovníkům (třída Worker) snížit o 500. Méně zkušený vývojář by v takovém případě možná napsal následující kód:

public void Foo(IEnumerable<Employee> employees) {
  foreach(var e in employees) {
    if (e is Manager) {
      e.Salary += 1000;
    } else {
      e.Salary -= 500;
    }
  }
}

Takový „if“ je přesně věc, která by se v pořádném OOP návrhu neměla objevit a tento kód přímo volá po použití virtuální metody. Problém je ale v tom, že jednou budeme chtít přidávat/ubírat peníze, jednou zase něco úplně jiného a ve výsledku bude třída Employee plná nekonzistentních virtuálních metod. (Puristé v tom už vidí poručení Open/Closed principu.) Nyní přichází na řadu multiple dispatch, přesněji double dispatch, protože budeme chtít vybírat metodu na základě aktuálního typu prvního parametru.

class ChangeSalary {
  public void Visit(Manager m) { m.Salary += 1000; }
  public void Visit(Worker m) { m.Salary -= 500; }
}
// ...
public void Foo(IEnumerable<Employee> employees) {
  var visitor = new ChangeSalary();
  foreach(var e in employees) {
    visitor.Visit((dynamic)e);
  }
}

Nyní můžeme snadno přidávat a odebírat různé další třídy podobné ChangeSalary, není třeba upravovat kód v třídě Employee a zbavili jsme se nechtěného ifu. Výše uvedený kód je v podstatě implementace návrhového vzoru Visitor, ovšem díky podpoře pro double dispatch přes dynamic je skutečně jednoduchá. Někteří vývojáři zastávají názor, že se v takovém případě už ani nedá mluvit o návrhovém vzoru, prostě jazyky, které podporují double dispatch, podle nich návrhový vzor Visitor nepotřebují. Lze se na to dívat i tak, že ačkoliv je implementace vzoru Visitor v tomto případě velmi jednoduchá, pořád za ní stojí základní myšlenka tohoto vzoru — odstranění příkazů if nebo switch, které testují aktuální typu objektu.

Co je tedy na vzoru Visitor tak složitého? Na to se podíváme v následující sekci.

Visitor bez double dispatch

Některé jazyky vůbec nepodporují double dispatch, například C++, a v některých jazycích použití double dispatch znamená drobné snížení výkonnosti (pamatujete na rozdíl mezi .call a .callvirt, v tomto případě je rozdíl ještě větší). Jak tedy implementovat double dispatch, když pro něj nemáme přímou podporu? Odpovědí je dvojité použití virtuálních metod. Následuje ukázka takové implementace a její popis.

abstract class Visitor {
  public virtual void Visit(Manager m) {}
  public virtual void Visit(Worker w) {}
}

abstract class Employee {
  public abstract void Accept(Visitor v);
}

class Manager : Employee {
  public override void Accept(Visitor v) {
    v.Visit(this);
  }
}

class Worker : Employee {
  public override void Accept(Visitor v) {
    v.Visit(this);
  }
}

class ChangeSalary : Visitor {
  public override void Visit(Manager m) {
    m.Salary += 1000;
  }
  public override void Visit(Worker w) {
    w.Salary -= 500;
  }
}

//...
var visitor = new ChangeSalary();
foreach(var e in employees) {
  e.Accept(visitor);
}

Pomocí virtuální metody Accept ve třídě Employee zjistíme aktuální typ objektů, které mají statický typ Employee — to znamená že je potřeba tuto metodu překrýt v každém potomkovi třídy Employee. Metoda Accept dostane instanci třídy Visitor, zavolá na ní další virtuální metodu Visit a jako parametr předá this. V tuhle chvíli má this správný statický typ, protože pomocí mechanizmu virtuálních metoda byla zavolaná metoda Accept na nějakém potomkovi Employee. Tohle už je trochu složitější. Důležité je, že pomocí uvedených tříd a metod se snažíme dosáhnout něčeho jako double dispatch. To je hlavní podstata návrhového vzoru Visitor.

Uvedený kód může být i názornou ukázkou, že správný vývojář by měl používat adekvátní postupy a metody. Počet řádků oproti původní verzi bez vzoru Visitor značně narostl. Přidali jsme nové třídy a virtuální metody, které je potřeba správně překrývat, i když kompilátor to nijak nevynucuje! Z pohledu našeho jednoduchého příkladu se původní kód proměnil v poměrně komplexní soustavu tříd zajišťující netriviální funkcionalitu (double dispatch) a přínos vzoru není tak úplně vidět.

Je tedy důležité podotknout, že návrhový vzor Visitor je doporučeno použít v situaci, kdy

• důležitost, rozsah a životnost projektu si vyžaduje použití tak komplexních řešení jako je návrhový vzor Visitor. Ještě horší než nerozumět návrhovým vzorům, je snažit se je aplikovat všude a bez rozmyslu.
• „Navštěnovanou“ hierarchii (Employee-Manager-Worker) tvoří spíše stabilní třídy, jejichž kód se často nemění a celkově do dané hierarchie nejsou často přidávány nové třídy.
• Operace na hierarchií, které jsou vlastně implementacemi třídy Visitor, často přibývají/ubývají.

Stejně jako většina ostatních postupů, kterými se typicky dosahuje zachování principu Open/Closed, porušuje návrhový vzor Visitor princip zapouzdření, protože „navštěvované“ objekty musí poskytovat veřejné vlastnosti (properties) a další metody, které jednotlivé implementace třídy Visitor potřebují, aby odvedly svoji práci.

Kde je to navštěvování?

Návrhový vzor Visitor podle svého názvu může evokovat představu, že jeho podstatou je rekurzivní navštěvování hierarchie tříd, jako v následující ukázce.

abstract class Visitor {
  public virtual void Visit(Layout layout) {}
  public virtual void Visit(Label label) {}
}

abstract class VisualElement {
  public abstract void Accept(Visitor v);
}

class Layout : VisualElement {
  private IList<VisualElement> children;
  //...**Důležitá část:**
  public override void Accept(Visitor v) {
    v.Visit(this);
    foreach(var c in this.children) {
      c.Accept(v);
    }
  }
}

class Label : VisualElement {
  public override void Accept(Visitor v) {
    v.Visit(this);
  }
}

class CountElements : Visitor {
  int layouts = 0;
  int labels = 0;
  public override void Visit(Layout layout) {
    this.layouts++;
  }
  public override void Visit(Label label) {
    this.labels++;
  }
}

//...
var visitor = new CountElements();
foreach(var e in visualElements) {
  e.Accept(visitor);
}

Ovšem kód, kde objekt typu Layout volá metodu Accept na agregovaných widgetech, není esenciální součástí vzoru Visitor, ale spíš ukázka kompozice vzoru Visitor a Composite (velmi často používaná varianta). V bibli návrhových vzorů „Gang of Four“ se můžeme dočíst, že procházení kolekce nebo hierarchie „navštěvovaných“ objektů může být realizováno v těchto objektech právě pomocí vzoru Composite, v samotné třídě Visitor nebo dokonce může být celé ponecháno na klientech.

Závěr

Návrhový vzor Visitor nám umožní implementovat double dispatch v jazycích, kde buďto není vůbec podporovaný, nebo jeho použití přináší určitý dopad na výkonnost. Díky double dispatch potom není třeba vytvářet konstrukce typu switch nebo zřetězené příkazy if-else-if, které testují aktuální typ objektu, což je obtížně rozšiřitelný a spravovatelný kód. Pokud povaha našeho programu povoluje použití klíčového slova dynamic, i přes nepatrné snížení výkonu, je vhodné jej použít pro implementaci double dispatch a zjednodušit tak výsledný kód; návrhový vzor Visitor se v takovém případě z kódu téměř vytrácí.

Limitations

At the moment it does not resolve generic arguments recursively, so for IDictionrary<string, int> it will return also IEnumerable<KeyValuePair<TKey, TValue>> instead of correct IEnumerable<KeyValuePair<string, int>>.

Disclaimer

I admin that the code is not as nice as it should be and it definitely contains some nasty bugs, which will appear under some esoteric circumstances, however on coming deadline is pushing me to do a few technical debts. Despite that I think some other people might find it helpful, at least as a starting point to their own implementation.

I would also like to thank to Jb Evains for creating and maintaining Cecil.

        public static IEnumerable<TypeReference> GetBaseTypes(
			this TypeDefinition type,
			bool includeIfaces)
        {
            Contract.Requires(type != null);
            Contract.Requires(
				type.IsInterface == false,
				"GetBaseTypes is not valid for interfaces");

            var result = new List<TypeReference>();
            var current = type;
            var mappedFromSuperType = new List<TypeReference>();
            var previousGenericArgsMap =
				GetGenericArgsMap(
					type,
					new Dictionary<string, TypeReference>(),
					mappedFromSuperType);
            Contract.Assert(mappedFromSuperType.Count == 0);

            do
            {
                var currentBase = current.BaseType;
                if (currentBase is GenericInstanceType)
                {
                    previousGenericArgsMap =
							GetGenericArgsMap(
								current.BaseType,
								previousGenericArgsMap,
								mappedFromSuperType);
                    if (mappedFromSuperType.Any())
                    {
                        currentBase = ((GenericInstanceType)currentBase)
							.ElementType.MakeGenericInstanceType(
								previousGenericArgsMap
									.Select(x => x.Value)
									.ToArray());
                        mappedFromSuperType.Clear();
                    }
                }
                else
                {
                    previousGenericArgsMap =
						new Dictionary<string, TypeReference>();
                }

                result.Add(currentBase);
                current = current.BaseType.SafeResolve(
                    string.Format(
						CannotResolveMessage,
						current.BaseType.FullName,
						current.FullName));
                if (includeIfaces)
                {
                    result.AddRange(BuildIFaces(current, previousGenericArgsMap));
                }
            }
            while (current.IsEqual(typeof(object)) == false);

            return result;
        }

        private static IEnumerable<TypeReference> BuildIFaces(
			TypeDefinition type,
			IDictionary<string, TypeReference> genericArgsMap)
        {
            var mappedFromSuperType = new List<TypeReference>();
            foreach (var iface in type.Interfaces)
            {
                var result = iface;
                if (iface is GenericInstanceType)
                {
                    var map =
						GetGenericArgsMap(
							iface,
							genericArgsMap,
							mappedFromSuperType);
                    if (mappedFromSuperType.Any())
                    {
                        result = ((GenericInstanceType)iface).ElementType
                            .MakeGenericInstanceType(
								map.Select(x => x.Value).ToArray());
                    }
                }

                yield return result;
            }
        }

        private static IDictionary<string, TypeReference> GetGenericArgsMap(
            TypeReference type,
            IDictionary<string, TypeReference> superTypeMap,
            IList<TypeReference> mappedFromSuperType)
        {
            var result = new Dictionary<string, TypeReference>();
            if (type is GenericInstanceType == false)
            {
                return result;
            }

            var genericArgs = ((GenericInstanceType)type).GenericArguments;
            var genericPars = ((GenericInstanceType)type)
				.ElementType.SafeResolve(CannotResolveMessage).GenericParameters;

            /*
             * Now genericArgs contain concrete arguments for the generic
			 * parameters (genericPars).
             *
             * However, these concrete arguments don't necessarily have
			 * to be concrete TypeReferences, these may be referencec to
			 * generic parameters from super type.
             *
             * Example:
             *
             *      Consider following hierarchy:
             *          StringMap<T> : Dictionary<string, T>
             *
             *          StringIntMap : StringMap<int>
             *
             *      What would happen if we walk up the hierarchy from StringIntMap:
             *          -> StringIntMap
             *              - here dont have any generic agrs or params for StringIntMap.
             *              - but when we reesolve StringIntMap we get a
			 *					reference to the base class StringMap<int>,
             *          -> StringMap<int>
             *              - this reference will have one generic argument
			 *					System.Int32 and it's ElementType,
             *                which is StringMap<T>, has one generic argument 'T'.
             *              - therefore we need to remember mapping T to System.Int32
             *              - when we resolve this class we'll get StringMap<T> and it's base
             *              will be reference to Dictionary<string, T>
             *          -> Dictionary<string, T>
             *              - now *genericArgs* will be System.String and 'T'
             *              - genericPars will be TKey and TValue from Dictionary
			 * 					declaration Dictionary<TKey, TValue>
             *              - we know that TKey is System.String and...
             *              - because we have remembered a mapping from T to
			 *					System.Int32 and now we see a mapping from TValue to T,
             *              	we know that TValue is System.Int32, which bring us to
			 *					conclusion that StringIntMap is instance of
             *          -> Dictionary<string, int>
             */              

            for (int i = 0; i < genericArgs.Count; i++)
            {
                var arg = genericArgs[i];
                var param = genericPars[i];
                if (arg is GenericParameter)
                {
                    TypeReference mapping;
                    if (superTypeMap.TryGetValue(arg.Name, out mapping) == false)
                    {
                        throw new Exception(
                            string.Format(
                                "GetGenericArgsMap: A mapping from supertype was not found. " +
                                "Program searched for generic argument of name {0} in supertype generic arguments map " +
                                "as it should server as value form generic argument for generic parameter {1} in the type {2}",
                                arg.Name,
                                param.Name,
                                type.FullName));
                    }

                    mappedFromSuperType.Add(mapping);
                    result.Add(param.Name, mapping);
                }
                else
                {
                    result.Add(param.Name, arg);
                }
            }

            return result;
        }

Entlib, jak se její jméno obvykle zkracuje, uchovává konfiguraci hlavně v xml souborech a to především v App.config případně Web.config. Konfigurace Entlib může být pěkně rozsáhlá a orientovat se v jednom obrovském xml souboru, to nemusí být jednoduché. Nehledě na typické problémy se systémem správy verzí (svn/mercurial/git/…) V následujícím obrázkovém návodu ukážu jak nastavit Entlib tak, aby konfiguraci brala z více souborů.

Budu předpokládat, že Entlib už je nainstalovaná a potřebné sestavy (assembly) jsou nareferencované. Použijeme grafický konfigurační nástroj, odpovídající akce by bylo možné provést i ruční editací xml souborů.

Mohlo by se zdát, že tím je vše hotové, ale pozor. Ještě je třeba Entlib říct, co bude další konfigurační soubor obsahovat — jaké bloky budou nakonfigurovány v něm. Konfiguraci ostatních bloků bude Entlib stále brát z App.config resp. Web.config.

Jak má vypadat formát souboru entlibconfig.xml? Úplně stejně jako App.config nebo Web.config. Tady je ukázka souboru, který obsahuje pouze konfiguraci logovacího bloku. Tento soubor můžete editovat pomocí grafické utility úplně stejně jako Web.config.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
    <section name="loggingConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="true" />
    </configSections>
<loggingConfiguration name="Logging Application Block" tracingEnabled="true"
    defaultCategory="General" logWarningsWhenNoCategoriesMatch="true">
    <listeners>
      <add name="Flat File Trace Listener" type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.FlatFileTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.FlatFileTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        fileName="trace.log" formatter="Text Formatter" />
    </listeners>
    <formatters>
      <add type="Microsoft.Practices.EnterpriseLibrary.Logging.Formatters.TextFormatter, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        template="Timestamp: {timestamp}{newline}&#xA;Message: {message}{newline}&#xA;Category: {category}{newline}&#xA;Priority: {priority}{newline}&#xA;EventId: {eventid}{newline}&#xA;Severity: {severity}{newline}&#xA;Title:{title}{newline}"
        name="Text Formatter" />
    </formatters>
    <categorySources>
      <add switchValue="All" name="General">
        <listeners>
          <add name="Flat File Trace Listener" />
        </listeners>
      </add>
    </categorySources>
    <specialSources>
      <allEvents switchValue="All" name="All Events" />
      <notProcessed switchValue="All" name="Unprocessed Category" />
      <errors switchValue="All" name="Logging Errors &amp; Warnings">
        <listeners>
          <add name="Flat File Trace Listener" />
        </listeners>
      </errors>
    </specialSources>
  </loggingConfiguration>
</configuration>

Pokud to myslíte s unit testy, potažmo TDD, opravdu velmi vážně, pak by pro vás neměla být následující ukázka překvapivá.

    public class Rectangle
    {
        public Rectangle(int width, int height)
        {
            this.Width = width;
            this.Height = height;
        }

        public int Width { get; private set; }
        public int Height { get; private set; }
    }	

	[TestFixture]
	public class RectangeTest
	{
		[Test]
		public void Fields_Of_Rectangle_Are_Assigned()
		{
			var r = new Rectangle(3, 4);
			Assert.AreEqual(3, r.Width);
			Assert.AreEqual(4, r.Height);
		}
	}

I ve dvou přiřazeních v konstruktoru se dá teoreticky udělat chyba, třeba je někdo může omylem prohodit. Podívejte se ale pozorně na výše uvedený test. Přijde vám na něm něco zvláštního? Napsat takový test je naprosto rutinní záležitost, možná bychom měli přenechat dřinu strojům…

Kontrakty na scénu

Výsledkem volání uvedeného konstruktoru, není nic, co by se nedalo popsat jednoduchou podmínkou. Oproti tomu, pokud máme implementovat metodu, co má v zadaném grafu najít nejkratší cestu, těžko popíšeme výsledek vzhledem k vstupním datům, to bychom museli pro ověření správnosti výsledku výsledek znovu vypočítat — nebo-li definice kruhem. Zpět k obdélníku. Podívejme se na verzi s kontrakty pro post-condition (=podmínky, co mají platit po provedení metody).

    public class Rectangle
    {
        public Rectangle(int width, int height)
        {
            Contract.Ensures(this.Width == width);
            Contract.Ensures(this.Height == height);

            this.Width = width;
            this.Height = height;
        }

         // ...
    }

V podstatě jsme zapsali to samé, co v unit testu, ale přehledněji, čistě deklarativně a v kódu „testované“ třídy. Nicméně, v této verzi unit test chybí. Může tohle standardní milovník TDD akceptovat, aniž by autorovi tohoto kódu vyhlásil džihád? Odpověď je ano, může! Pokud máte nainstalované Code Contracts, zkuste prohodit width a height v přiřazovacích příkazech. Statická kontrola vám po kompilaci ihned ukáže chybu, protože za nás v podstatě udělala ten nudný unit-test z úvodu. Dokonce víc. Code Contracts provedly (logický) důkaz, že kód je správně. Takže nechme dřinu strojům a soustřeďme se na testování opravdu složitého kódu, který nelze ověřit statickou analýzou, třeba to hledání nejkratší cesty v grafu.

Co si myslíte o nahrazení unit-testů odpovídajícími kontrakty vy?

Disclaimer: Code Contracts mají v současné verzi svoje mouchy. Syntaxe by taky mohla být hezčí. Prodloužená doba kompilace při použití Contracts se nemusí líbit každému. Ano unit-testování přiřazovacích příkazů, stejně jako psaní post-conditions pro jejich ověření, se může někomu jevit jako zbytečnost.

Nahrazení *textu v hvězdičkách* za <b>textu v hvězdičkách</b>

Regex.Replace(sourceString, @"\*(?<bold>[^\*]*)\*", @"<b>${bold}</b>");

Pojmenovaná skupina začíná závorkou, otazníkem a jménem skupiny ohraničeného většítkem a menšítkem, dále pokračuje tělo skupiny — tedy regulární výraz, který bude zachycovat znaky, co ještě „patří do skupiny“ — a končí závorkou. Při nahrazování (případně jiných operacích) se lze na obsah pojmenované skupiny odvolat pomocí syntaxe ${jmenoSkupiny}.

Zkuste si představit, že všechny texty určené pro uživatele získáváte pomocí volání metody Translate(„idPrekladu“) a chcete získat všechny parametry, se kterými je tato metoda zavolána.

var matches = Regex.Matches(
     File.ReadAllText("soubor.cs"),
     @"Translate\(""(?<id>[^""]*)""\)");

foreach (Match match in matches)
{
    Console.WriteLine(match.Result("${id}"));
}

Jistě znáte soubory s příponou vcproj, případně vbproj pro Visual Basic. Jsou to projekty pro Visual Studio, takže je, přirozeně, otevíráte ve Visual Studiu, ale zkusili jste je někdy otevřít v obyčejném textovém editoru? Pokud byste tak učinili, uviděli byste něco podobného jako v následující ukázce:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://...">
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <!-- a tak dále ... -->

už podle první řádky je jasné, že se jedná o xml. Konkrétně je to xml dialect určený pro MSBuild. Tento program, který naleznete na cestě „C:\Windows\Microsoft.NET\Framework\{verzeNET}\MSBuild.exe“, je interpretem speciálního deklarativního na xml postaveného jazyka. Podrobnou syntaxi naleznete v jiných článcích na internetu, pro účely spuštění unit testů po buildu si vysvětlíme nutné základy.

Formát MSBuild umožňuje definovat tzv. cíle (target). Atribut DefaultTargets kořenového uzlu Project určuje cíl, který bude defaultně spuštěn. Cíl může spouštět další cíle a úkoly (task). Význam úkolů si objasníme později. Kromě úkolů a cílů můžeme pro zpřehlednění kódu definovat něco jako proměnné. V souboru csproj, který pro nás vygenerovalo Visual Studio, můžeme nalézt zakomentované následující cíle:

  <!-- To modify your build process, add your task inside one of the targets below and uncomment it. -->
  <Target Name="BeforeBuild">
  </Target>
  <Target Name="AfterBuild">
  </Target>

Tyto cíle, jak podle jejich jména jistě tušíte, budou spuštěny před a po buildu. Takže pro spuštění unit testů není potřeba nic většího než je odkomentovat a přidat nějaký obsah. Tím obsahem bude zavolání nunit.exe (nahraďte si svým oblíbeným unit-test frameworkem) a k tomu slouží předdefinovaný úkol (task) Exec, který je standardní součástí instalace MSBuildu.

<Target Name="AfterBuild">
  <Exec
    Condition="$(Configuration) == Debug"
    Command="
       &quot;C:\Program Files\NUnit\bin\net-2.0\nunit-console.exe&quot;
       &quot;$(OutputPath)Tests.dll&quot;" />
</Target>

Atribut Condition určuje podmínku, za které bude úkol spuštěn. Atribut Command určuje příkaz — sem napíšeme to samé, jako kdybychom chtěli unit testy spustit z příkazové řádky. Uzávorkované a znakem dolaru uvozené části (např. $(OutputPath)), jsou zmíněné „proměnné“. Využili jsme dvou proměnných, které pro nás zadefinovalo už Visual Studio. OutputPath určuje cestu, kde budou umístěny sestavy (assembly), které jsou výsledkem buildu. Význam Configuration byl měl být jasný.

Nyní je vše nastaveno. Po každém buildu se spustí unit-testy a pokud některý z nich selže, nunit.exe vrátí kód chyby a celý build selže. Obecně lze následující metodu použít pro spuštění jakékoliv akce ihned po buildu nebo i před buildem.

Update: objevil jsem zajímavý nástroj AutoTest.Net, který umí zařídit automatické spouštění testů hned po uložení souboru.

Spočívá v použití mírně upravené varianty tzv. „Type safe enum„. Tento vzor spočívá v tom, že třídě, která má být naším „enumem“, skryjeme konstruktor, tak abychom instanci mohli vytvořit jenom „zevnitř“, a „navenek“ nabídneme jenom omezené množství instancí prostřednictvím readonly statických členů.

    public class Planet
    {
        public static readonly Planet Mercury = new Planet();
        public static readonly Planet Venus = new Planet();
        public static readonly Planet Earth = new Planet();
        public static readonly Planet Mars = new Planet();

        private Planet() {}
    }

    // ....
    Planet p = Planet.Mercury;
    if (p == Planet.Earth) ...

Entity Framework ale potřebuje nějak rozlišit jednotlivé instance podle dat. Data zatím nemáme žádná. Můžeme vytvořit jedno-účelnou „diskriminační“ property například typu int. Navíc privátní parametrický konstruktor by se EF taky nelíbil, takže přidáme další protected bezparametrický konstruktor. To je ústupek, který musíme často podstoupit i v případě NHibernate, privátní konstruktory nemá ráda většina ORM, protože potřebují vytvářet dynamické proxy. Musíme také přetížit operátor porovnání, aby porovnával na základě hodnoty „diskriminační“ property. Místo jedno-účelové property můžeme případně použít i něco smysluplnějšího, například u dnů v týdnu by to mohlo být jejich pořadové číslo. Výsledná třída bude vypadat následovně:

    public class Planet
    {
        public static readonly Planet Mercury = new Planet(0);
        public static readonly Planet Venus = new Planet(1);
        public static readonly Planet Earth = new Planet(2);
        public static readonly Planet Mars = new Planet(3);

        private Planet(int dicriminator)
        {
            this.Dicriminator = dicriminator;
        }

        protected Planet() {}

        public int Dicriminator { get; set; }

        public static bool operator ==(Planet planet1, Planet planet2)
        {
            return planet1.Dicriminator == planet2.Dicriminator;
        }

        public static bool operator !=(Planet planet1, Planet planet2)
        {
            return !(planet1 == planet2);
        }

        // spravne bychom meli prekryt i metody Equals a GetHashCode
    }

Entity Framework by měl třídu Planet rozpoznat jako „komplexní typ“ (v řeči NHibernate komponentu) nebo-li třídu, pro kterou nebude vytvářet samostatnou tabulku. Mně ale tohle nefungovalo, takže jsem EF instruoval v tomto směru ručně.

    public class Context : DbContext
    {
        // ...
        protected override void OnModelCreating(ModelBuilder modelBuilder)
        {
            modelBuilder.ComplexType<Planet>();
        }
    }