Trouwens, in plaats van een setEntityManager() methode aan je EJB/DAO toe te moeten voeten, zou je ook zelf de EntityManager kunnen “injecteren” in je testclasses, bij voorbeeld met de onderstaande methodes.

(Dit is min of meer hoe het trouwens ook gedaan word in de container/via de annotaties)


public static boolean setEntityManager(Object daoBean, EntityManager entityManager) {
boolean fieldSet = true;

try {
field.set(fieldObject, fieldValue);
fieldSet = true;
}
catch(Exception e) {
logger.warn("Unable to set field '" + field.getName() + "' on " + fieldObject.getClass().getSimpleName()
+ ": [" + e.getClass().getSimpleName() + ": " + e.getMessage() + "]");
}
return fieldSet;
}

Dat is niet helemaal waar – java.util.Date objecten bevatten alleen een aantal milliseconden (sinds 01-01-1970 00:00:00 UTC), geen timezone. Eén van de dingen die vaak verwarrend is voor programmeurs is dat class Date niets weet van timezones.

“Om bijvoorbeeld het jaar van een Calendar object met de naam cal op te vragen ziet de aanroep er als volgt uit: cal.get(YEAR) waarbij YEAR een constante is die op Calendar is gedefinieerd.”

Dit is inderdaad erg lelijk, een vorm van het magical strings anti-pattern: http://wiki.apidesign.org/wiki/MagicalStrings

Gebruikers, als in eind-gebruikers, bezoekers van de website bijv, willen natuurlijk helemaal geen errors zien. In production-mode zal je dus een vriendelijke error-pagina moeten maken, terwijl de errors gelogd worden voor de developers. In development en test-mode wil je die errors gewoon gelijk zien zodra ze gebeuren. Dit heeft niks met statisch of dynamische code te maken.

De gebruiker van de ‘interface’ is een programmeur. Die wilt tijdens het ontwikkelen ook errors zien.

Ik ontken niet dat type-restricties in interfaces niet helpen, maar dan alleen in een statische taal. In een dynamische taal als Ruby geef je alleen een andere error die je wellicht toch al gekregen zou hebben. Alles in Ruby is immers runtime. Of ik nu de error krijg dat de eerste parameter een Eend-object moet zijn, en niet een Kat-object of dat de methode ‘vlieg()’ niet bestaat op mijn Kat-object, ik kan met beiden uit de voeten. Ik heb denk ik zelfs meer aan de tweede error, aangezien ik daarmee wel mijn Vleermuis-object kan gebruiken. Als ik als type restrictie ‘Vogel’ zou hebben had ik mijn Vleermuis-object ook niet kunnen gebruiken, terwijl ik alleen geinteresseerd ben in het vlieggedrag.

Statisch vs. Dynamisch is ook een eindeloze discussie. Ik durf niet te zeggen welke beter is. Ik durf wel te zeggen dat in een taal die dynamisch is, je niet statisch moet proberen te programmeren. Dat levert alleen maar ellende op.

Checken van types hoeft ook echt niet overal, maar in interfaces is het absoluut aan te raden. Dat is wel iets wat je met static typing oplost, maar het brengt ook weer een sloot restricties met zich mee. Je helpt hiermee de gebruiker van de code enorm.

Iedere programmeur die zijn vak al een hele tijd uitoefent zal zeggen dat mens leesbare code belangrijker is dan computer efficiënte code. Dit heeft niets met de taal te maken. Wat leesbaar is, is voor iedereen weer anders. Dit heeft meer te maken of je alles expliciet wilt zien of genoegen neemt met wat de syntax impliceert. Dit heeft meer te maken met de code style discussie dan met de code standards die we allemaal aanhouden.

Bij het proces van vertellen aan de computer wat die moet doen heb je voor elk aspect een regel nodig. Als er veel regels zijn dan hoef je minder zelf te bedenken. Als er weinig regels zijn moet je de ongedekte aspecten zelf invullen. De vrijheid van een taal hangt heel dicht samen met of iets expliciet moet zijn, een regel heeft, of niet. Als er geen regel is heb je de vrijheid om het zelf in te vullen, maar als je de belangrijke aspecten niet invult zul je zeker in de problemen komen. Sommige talen streven naar ultieme vrijheid. Anderen streven naar een volledige set van regels. Wat voor hippie of control-freak ben jij?

In het boek “Coders at Work” stelt de interviewer altijd de vraag: Do you consider yourself a scientist, an engineer, an artist or a craftsman? Elke taal is bedacht door een programmeur die in minstens één van deze omschrijvingen past. Een taal erft de eigenschappen van de programmeur. De taal die het beste bij jou past is waarschijnlijk de taal die geschreven is door een programmeur die zichzelf hetzelfde ziet als jou.

De argumenten om VOOR Ruby te kiezen zouden ook juist redenen kunnen zijn om het niet te doen. Ik ben het daarom helemaal eens met de conclusie.

Het niet nodig hebben van static typing in Ruby past helemaal bij de filosofie dat “de verantwoordelijkheid van het juist gebruiken van een library ligt bij de gebruiker en niet de maker van de library”. Een vereiste hierbij is dat je kunt zien waar het object aan moet voldoen als het erin gaat. Documentatie van de public API moet dan heel uitgebreid zijn of je moet kunnen zien wat er gebeurd. Ruby levert de laatste optie. Je gaat static typing missen als je niet goed meer kunt achterhalen wat er gebeurd.

>> wat onderscheid Rubyesque nu precies van algemeen aanvaarde best practices?

Ben blij dat jij dat algemene best parctices vindt

>> “You’re checking for null values all over the place.”

Dat probleem los je niet op met een static typing

>> There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this a kind of User object? Because that’s what we’re expecting. If we don’t get that, this is going to explode.”

En dan wat? Raise je een error als je niet het juiste type object krijgt? Dat is ook een explosie. Of log je de boel alleen? Op het moment dat je een object krijgt waar je niks mee kan, is het in dynamische talen al te laat. De code is al aan het uitvoeren. Wat dit met lange uptimes te maken heeft weet ik niet.