Ich möchte hier das Beispiel der Dokumentation aufgreifen.
Von einer Basisklasse „Employee“ werden zwei weitere Klassen „Manager“ und „Engineer“ abgeleitet.

Grundsätzlich gibt es verschiedene Strategien Klassenhirarchien abzubilden

• Joined Table Inheritance:
  Bei dieser Variante gibt es für jede Klasse eine eigene Tabelle. Die beiden Subklassen erhalten eigene Tabellen mit Referenzen auf die Basisklasse.
• Single Table Inheritance:
  In dieser Form wird die ganze Klassenhierarchie in einer einzelnen Tabelle abgebildet. Aus Blick des Python Codes ist alles sauber. In der Datenbank gibt es aber in der Tabelle Felder, die nur abhängig vom Typ befüllt werden dürfen. Echte Datenbank-Constraints sind damit fast unmöglich.
• Concrete Table Inheritance:
  Hier gibt es auch wieder für jede Klasse eine Tabelle. Diesesmal haben die Subklassen aber keine Foreign Key Beziehung mit der Basisklasse. Jede Tabelle dupliziert auch die Spalten der Basisklasse. Aus Sicht der Datenbank gibt es nun keine Zentrale Tabelle mehr in der alle „Employees“ erfasst sind. Es lässt sich damit auch kein Foreign Key Constraint mehr setzen.

Um ein sauberes Datenbankmodell zu erhalten, ist somit nur die „Joined Table Inheritance“ zu empfehlen:

• Auf Spaltenebene können ohne Problem Check-Constraints und Not-Null-Constraints definiert werden.
• Auch ohne die Kenntnis des SQLALchemy Mappings ergibt sich für andere Anwendungen ganz automatisch welche Felder für welche Klasse gefüllt werden können.
• Die Basisklasse kann durch andere Tabellen via Foreign Key Constraint referenziert werden.

Wie wird nun eine Joined Table Inheritance in Python gemappt?

class Employee(Base):
    __tablename__ = 'employee'
    Id = Column(Integer
                , primary_key=True)
    Name = Column(String(50))

class Manager(Employee):
    __tablename__ = 'manager'
    Id = Column(Integer
                , ForeignKey(Employee.Id)
                , primary_key=True)
    ManagerStatus = Column(String(50))

    __mapper_args__ = {
        'polymorphic_identity': 'manager',
    }

class Engineer(Employee):
    __tablename__ = 'engineer'
    Id = Column(Integer
                , ForeignKey(Employee.Id)
                , primary_key=True)

    EngineerDegree= Column(String(50))

    __mapper_args__ = {
        'polymorphic_identity': 'engineer',
    }

Daraus lassen sich diese Create-Statements generieren.

create_engine('sqlite:///', echo= True)
Base.metadata.create_all(bind=engine)

CREATE TABLE employee (
	"Id" INTEGER NOT NULL, 
	"Name" VARCHAR(50), --Felder der Basisklasse sind hier  ...
	PRIMARY KEY ("Id")
);
-- und werden in den abgeleiteten Tabelle nicht mehr wiederholt
CREATE TABLE engineer (
	"Id" INTEGER NOT NULL, 
	"EngineerDegree" VARCHAR(50), 
	PRIMARY KEY (id), 
	FOREIGN KEY(id) REFERENCES employee ("Id")
);

CREATE TABLE manager (
	"Id" INTEGER NOT NULL, 
	"ManagerStatus" VARCHAR(50), 
	PRIMARY KEY (id), 
	FOREIGN KEY(id) REFERENCES employee ("Id")
);

Wichtig ist dabei der Fremdschlüssel in den abgeleiteten Klassen, der auf die Basisklasse zeigt:

#Employee.Id bezieht sich dabei auf den Klassen/Attributnamen,
#nicht etwa auf Tabellen oder Spaltenbezeichnungen
Id = Column(Integer,ForeignKey(Employee.Id), primary_key=True)

Vergisst man diesen Fremdschlüssel erhält man folgende Meldung:

  Can’t find any foreign key relationships between ‚employee‘ and ‚manager‘.

strPattern = "^([a-zA-Z0-9_\-\.]+)@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,3})$"

In diesem Blogpost geht es mir im besonderen um das Matching der Toplevel-Domain. Dabei ist vielfach noch hinterlegt, dass diese zwischen zwei und drei Buchstaben lang sein muss. Das gilt aber leider nur bei „country code top level domains“, die eben einem Land gehören. Generische Top Level Domains sind meist länger. Eine“.info“-Domain ist valide, würde aber von obigem Regex nicht gematcht.

strPattern = "^([a-zA-Z0-9_\-\.]+)@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,})$"

Obiger Regex ist derweil immer noch nur eine Näherung an den IEEE-Standard, filtert aber längere Toplevel-Domains nicht mehr aus.

Zur Installation genügt auf dem auf Debian basierenden Raspbian der Aufruf des Paketmanagers auf der Konsole:

sudo apt-get install mono-complete

Nachdem nun die eigene .Net App auf den Raspy kopiert wurde lässt sie sich einfach starten:

mono APP-NAME.exe

Grundsätzlich funktioniert die Installation auch über:

sudo apt-get install mono

Dies produziert dann beim Start  einer eigenen App eine Menge Assembly Not Found Exceptions.

Extension Methods wurden mit .Net 3.5 eingeführt und erlauben es einen Type zu erweitern ohne von ihm abzuleiten. So können bequem sogar „sealed“ Types wie System.String erweitert werden – z.B. um eigene Substring Funktionen. Eine ebenfalls sehr nützliche Funktionalität ist es (generische) Interfaces mit konkretem Code zu hinterlegen, ohne alle Ableitungen des Interfaces zu überarbeiten zu müssen. Eine Extension Method zu IList erweitert also sofort alle Klassen die darauf aufbauen.

Das alles macht im ersten Moment den Eindruck einer Mehrfachvererbung. Das suggeriert auch Visual Studio, indem es die Extension- mit den Instanz-Methoden zusammen anzeigt:In Wirklichkeit handelt es sich aber nur um „Syntax Sugar„, also einer reinen Vereinfachung für den Programmierer – intern sind das verschiedene Klassen.

Das hat mehrere Konsequenzen:

• Extension Methods können keine Interfaces implementieren
• sie können keine abstracten Methoden ausprogrammieren
• per Reflection sind Extensions nicht in der eigentlichen Klasse zu finden

Der Versuch die Extension auf normalem Wege per Reflection zu finden scheitert:

MethodInfo method = typeof(MyClass)
   .GetType()
   .GetMethod("ExtensionMethod");
Assert.IsNotNull(method); //Dieser Test wird scheitern

Die gesuchte Methode ist eben nicht im gleichen Typ definiert, sondern in einer beliebigen anderen Klasse.

Um alle Extension Methods zu einer bestimmten Klasse zu finden, ist es notwendig alle Typen der Assembly (oder AppDomain) nach Methoden zu durchsieben die zum gesuchten Type („TypeToSearchFor“) erfüllen:

var methods = TypeToSearchFor.Assembly
  .GetTypes()
  .Where(t =>
       t.CustomAttributes
       .where(a => a.AttributeType == typeof(ExtensionAttribute))
       .Count() == 1
       )
  .SelectMany(t => t.GetMethods())
  .Where(m=>m.IsStatic == true)
  .Where(m => m.GetParameters().Count() != 0)
  .Where(m => m.GetParameters()[0].ParameterType == TypeToSearchFor)
  ;

Als Anhang befindet sich ein Testprojekt mit :

• BeispielKlasse und Extension dazu
• TestProjekt mit Reflection zum Suchen der Methoden
• ReflectionHelper Klasse zum Suchen aller Extension Methods

Ein Ansatz um den Code in Zahlen zu fassen sind Code Metriken… Visual Studio 2010 Team Foundation Edition hat das bereits integriert und liefert auf Knopfdruck eine Auswertung aller bestehenden Klassen und Methoden.

• Maintainability Index
• Cyclomatic Complexity
• Depth of Inheritance
• ClassCoupling
• Lines of Code

Aber was hat das nun zur Aussage ?

Von hinten angefangen:

Lines of Code
Das ist wohl das am leichtesten zu verstehende Metrik, und bezeichnet schlicht und ergreifend die Anzahl der Zeilen pro Klasse. Wer hier Klassen findet, die jenseits der 1.000 (oder 10.000 !!??) oder Methoden die jenseits der 100 Zeilen gefunden hat, ist vom Hot Spot des Codes nicht weit entfernt.

Class Coupling
Bezeichnet die Anzahl der Klassen die von dieser Klasse oder Methode referenziert werden. Um so mehr Klassen benutzt werden, um so komplizierter der (Unit-) Test , um so schwerer die Wiederverwendung. Gibt es wenige Objekte die quasi alle anderen Klassen referenzieren ist dies die Implementierung eines God-Object-Antipatterns.

Depth of Inheritance
Auch hier gilt, um so mehr Ableitungen, um so schwerer ist es für jemand aussenstehenden sich einzuarbeiten. Mit dieser Metrik konnte ich bisher am wenigstens anfangen, da viele Objekte z.B. für die Peristierung relativ unkritische Basisklassen besitzen.

Cyclomatic Complexity
Salop formuliert, wird bei dieser Metrik die Anzahl der Kontrollstrukturen (if, switch…) gezählt. Je höher desto schlechter.
Auf die Klasse gesehen ist die Aussagekraft meiner Meinung nach nicht hoch, für die einzelne Methode allerdings um so mehr! Eine Methode mit vielen komplexen, verschachtelten If-Statements macht die Einarbeitung nicht leichter. Gerne wird dieser Code auch mit Antipattern wie Magic Strings kombiniert.
Diese Problematik lässt sich i.d.R. durch bessere Strukturierung des Codes und Objektorientierung vermeiden.

Maintainability Index
… ist sozusagen das Aggregat aus allen anderen Metriken. Je niedriger desto schlechter.
Visual Studio markiert alles unter 30 als rot. Meiner Erfahrung nach ist die Grenze des Guten schon bei unter 50 erreicht und ein Blick in den Code ist notwendig.

Erfahren Sie hier mehr darüber !

Ich freue mich über Ihr Feedback!

public class Person
{
public int ID { get; set; }
public string Vorname { get; set; }
public string Nachname { get; set; }
}

Das Sortieren nach Nachnamen ist noch einfach:

List<Person> personen = new List<Person>();
//.......Laden der Liste

personen.OrderBy(p => p.Nachname);

Aber was, wenn zwei Personen den gleichen Nachnamen haben?

personen.OrderBy(p => p.Nachname).OrderBy(p => p.Vorname);

Das ist nicht die Lösung. Die Liste wird nun nur noch nach Vorname sortiert.

Die Lösung ist die Extension „ThenBy“, damit wird nun innerhalb eines Nachnamens nach Vornamen sortiert – wie gewünscht!

personen.OrderBy(p => p.Nachname).ThenBy(p => p.Vorname);

Ich persöhnlich sortiere zum Schluss gerne noch nach etwas syntetischem – beispielsweise der ID.
Das hat den Vorteil, dass selbst im unmöglichsten Fall (in diesem Beispiel, dass zwei den gleichen Vor- und Nachnamen haben) immer eine definierte Reihenfolge festgelegt ist. Selbst in diesem Fall, erhält der User in der Oberfläche immer eine definierte Reihenfolge. Gerade bei PLinq kann man sich ja auf die Reihenfolge gar nicht mehr verlassen..

personen.OrderBy(p => p.Nachname).ThenBy(p => p.Vorname).ThenBy(p=>p.ID);

Diese bietet in ASP.Net Seiten ähnlich dem Application oder Session Object die Möglichkeit Werte/Objekte zu speichern, ist hier aber intelligenter und verwirft die Objekte nach einer festgelegten Zeitdauer. Die Intellisense Hilfe zu den Methoden ist selbsterklärend: Ablauf nach einer Zeitspanne, nach einem absolutem Datum …

Selbsterklärend ? Dachte ich…  Bei der Verwendung erhielt ich beim ersten Zugriff auf Cache aus einer aspx-CodeBehind-Klasse heraus eine HTTPException mit der Meldung „Cache is not available“ bzw „Cache ist nicht verfügbar“.  Lange habe ich nach der Lösung gesucht; vielleicht muss man den Cache ja irgendwo (web.config, Page Directive etc) aktivieren?! Aber nichts. Auch Google stellt sich dumm.

Letztenendes ist die Lösung einfach statt nur „Cache.Get(…“  „HttpContext.Current.Cache…“ zu verwenden. Leider habe ich keine Erklärung parat woran es liegt ?!

Auf der Suche nach Erklärungen habe ich mich nun selber auch mal mit der Performance von alltäglichen Code beschäftigt. Wie wäre es z.B. mit String Operationen ? Da gibt es doch immer das Gerücht, das die Verbindung von Strings über „+“ viel zu langsam ist. Damit fange ich doch gleich mal an….Also schnell mal den Code hier hingepinselt (Code1) und auch gleich die Verbesserung dazu (Code2).

//Code1
Stopwatch watch = Stopwatch.StartNew();
string res = "abc" + "abc123";
watch.Stop();

//Code2
Stopwatch watch = Stopwatch.StartNew();
string res = String.Concat("abc" + "abc123");
watch.Stop();

Die Klasse Stopwatch zeigt, wie der Name schon sagt, die vertrichene Zeit an. Mit etwas Code drum rum zum Aufwärmen und Mitteln der Ausführungszeiten komme ich zu dem Schluss, dass beide 0 Millisekunden brauchen. Ein unbefriedigendes Ergebnis. Also die Messung umgestellt auf Ticks. Das Ergebnis ist, dass mit jeder Wiederholung die Ergebnisse etwas variieren, zwischen 1 und 4 Ticks. Das ist kein Unterschied…  Was ist da also los ? Was macht .Net hier wirklich ?

Um das weiter zu analysieren gibt es Profiler. Es gibt diverse Kaufprodukte (z.B. Redgate Performance und Memory Profiler ), aber auch Microsoft bietet gut versteckt einen Memory Profiler an.  Unter dem Link gibt es den CLRProfiler für  .Net 4 direkt von Microsoft. Man startet über den Profiler sein eigenes Programm und kann auswerten was das eigene Programm so treibt.

32bit Profiler starten, „Start Application“, Pfad auswählen und Programm ausführen lassen. Nachdem es ausgeführt wurde, Klick auf View, Call Graph.

Das Erste was man sieht sind Unmengen von Aufrufen, die mit dem eigenen Programm nichts zu tun haben  – damit verbrät also .Net schon für ein einfaches Consolenprogramm mehrere MB…

Wenn man die Ansicht etwas einschränkt kommt folgendes Ergebnis für meine beiden Möglichkeiten heraus:

Zu sehen ist eine zusammengestellte, gefilterte Ansicht der beiden relevanten Methoden. Der übersichtlichkeit halber Methode2 vor Methode 1.

Was ist da zu sehen ? Die Methode StringConcat2 führt  –  wie auch im Code zu sehen  – String.Concat aus. Aber was ist da bei StringConcat1 passiert ? Da findet sich auch ein String.Concat Aufruf darin! Den Aufruf der Klasse Datetime habe ich selber noch eingefügt, um überhaupt einen Aufruf bei der zweiten Methode zu sehen. Anscheinend hat .Net meine sinnlose Verbindung von nichtssagenden Strings ebenfalls für sinnlos befunden und gleich mal wegoptimiert. Erst durch das Hinzufügen eines „+ Datetime.Now.ToString()“ habe ich quasi volle Überzeugungsarbeit geleistet, sodass der Profiler auch etwas anzuzeigen hatte …

Folgerungen:

• Das .Net-Runtime-Environment überarbeite den Code in nicht unerheblichem Maße
• Die Diskussion um die bessere Variante derart einfacher, einzeiliger Stringverkettungen ist denkbar unsinnig.

Am Montag war es dann soweit,mein erstes Coding-Dojo.

Ausgerichtet wurde es von der .Net Coding Dojo Gruppe.
Stattgefunden hat es bei Microsoft in Unterschleißheim bei München.
Die Aufgabe war einen Paginator zu bauen, also eine Klasse die die Seitenfunktionalität von Listen im Web abbildet.

Aufgeteilt in mehrere kleine Gruppen, war die Aufgabe mit Extreme Programming und TDD zu lösen.
Schon nach kurzer Zeit war die Diskussion groß, weil jeder für diese Aufgabe eine andere Lösung dazu im Kopf hatte oder gar die Aufgabe unterschiedlich verstanden hatte

Sehr interessant war dann auch, was dann nach ca. 3 Stunden bei den verschiedenen Gruppen herausgekommen ist, auch wenn längst nicht alle Gruppen die Anforderungen erfüllt haben.
Mein Lernerfolg fürs nächste mal: Ist die Aufgabe auch noch so einfach, Finger weg von der Tastatur und erst mal das Ziel definieren.

Prädikat: Empfehlenswert!