Jeg kom forleden til at se på en klasses interface og reflekterede i den forbindelse lidt over hvor logisk/intuitivt det interface var. Min konklusion var, at der var plads til forbedring...

Klassen tilbød noget i stil med dette:

public class Member {
   public Member(Guid id) { ... }
   public static Member GetByEmail(string email) { ... }
}

Hvor konstruktøren indlæser et Member på grundlag af det id der medsendes. Dette virker da også tilforladeligt, men ved nærmere eftertanke, synes jeg det virker lidt ulogisk. Observer flg. eksempel på brugen af denne klasse:

var member = new Member(memberId);

Skulle man læse ovenstående linje, ville det se ud til at man oprettede et nyt Member-objekt med et givet id. Dette er dog ikke tilfældet, idet man som sagt, henter et eksisterende Member-objekt med det givne id.

Jeg ville derfor vælge at lave endnu en statisk metode til at indlæse et Member-objekt med, dvs. noget i stil med flg.:

public class Member {
   public Member() { ... }
   public static Member Get(Guid id) { ... }
   public static Member GetByEmail(string email) { ... }
}

Nu ville flg. linje rent faktisk oprette et nyt Member-objekt:

var member = new Member();

og flg. linje ville afspejle hvad der rent faktisk foregik:

var member = Member.Get(memberId);

Dette er blot en lille overvejelse, men jeg synes det gør koden lettere at læse, fordi koden hjælper med at formidle hvad der rent faktisk foregår.

Man kunne evt. overveje om disse statiske metoder var bedre implementeret på en factory-klasse, som instance-metoder, men det er en diskussion som også involverer andre overvejelser, f.eks. om det kan betale sig i det aktuelle projekt og om der er andre behov som retfærdiggør at der skal oprettes en helt ny klasse, herunder løsere binding til Member-klassen. En løsere binding vil dog også kræve en abstraktion, f.eks. i form af et interface...