settembre 2006 Blog Posts
Qualcuno (diciamo alle prime armi con .NET) si potrebbe chiedere dove sta
l'implementazione di un evento di un'interfaccia, vista la sintassi C#:
interface
IFoo
{
event
EventHandler Bar;
}
class
Foo : IFoo
{
public
event
EventHandler
Bar;
}
Sembra che la classe Foo non implementi un bel nulla, e invece, con
questa sintassi, noi in realtà accettiamo l'implementazione di default
dei metodi add_Bar e remove_Bar, che la scriverà per noi il
compilatore (vedi il codice IL corrispondente). Meno confusione si crea
quando scegliamo di definire esplicitamente l'evento nella classe Foo;
lì i metodi delle funzioni di accesso add e remove tolgono ogni
dubbio sull'implementazione dell'evento.
Scrivete un metodo con il return type non void, che non abbia alcun return all'interno del suo corpo (e ovviamente che compili senza errori o warning).
Senza utilizzare alcun operatore aritmetico, proponete una soluzione per l'espressione ???expr??? = a * b nel seguente snippet, che utilizzi il minor numero di caratteri:
int Multiply(byte a, byte b){ return ???expr???;}
La mia ha 19 caratteri.
A volte, il codice "riflesso" con il Reflector, ci mette su false piste. Qualcuno, guardando per esempio l'implementazione dei singleton delle classi factory dei provider ADO.NET, tramite il Reflector, potrebbe erroneamente pensare che inizializzare esplicitamente un campo statico nel costruttore statico fosse una best practice:
// snippet 1// codice tramite il Reflectornamespace System.Data.SqlClient{ public sealed class SqlClientFactory : DbProviderFactory { public static readonly SqlClientFactory Instance; // codice non ottimizzato static SqlClientFactory() { Instance = new SqlClientFactory(); } private SqlClientFactory() { } // ... }}
E invece, il codice "reale" è questo:
// snippet 2namespace System.Data.SqlClient{ public sealed class SqlClientFactory : DbProviderFactory { ...