public UserCommandResult Execute()
{
var item = GetItem();
if (item.WasNotFound()) return ItemNotFoundResult();
if (item.CanNotBeCarried()) return ItemCanNotBeCarriedResult();
PickUp(item);
return SuccessResult();
}

Her skjuler det seg to null-tester.., men de er implementasjonsdetaljer. Koden lar seg nå lese som en god historie. \”If item can not be carried return item can not be carried result.\” Føles veldig riktig for meg.

Update: Merk at dette ikke er generelle extension methods for object. WasNotFound() skjekker derimot enkelt og greit om Item == null, mens CanNotBeCarried() bruker \”as\” nøkkelordet i C# til å kaste item til ICanBeCarried interfacet, og sjekker om resultatet av det er null. CanNotBeCarried() vil jeg ikke plassere på Item direkte, item er lukket for den type endringer. Etterhvert som jeg legger til flere item-egenskaper i form av ulike interfacer kan jeg legge til flere slike metoder uten å måtte endre Item.

Punkt 1, om jeg ville ha laget en IsReallyNotACustomer? Det kommer an på om jeg trengte det for å skrive lesbar kode. Kanskje har jeg behov for å sjekke at noe ikke er null, kanskje er behove å sjekke at det er null, kanskje er det begge deler. Jeg skriver ingen av dem før jeg ser at jeg behøver dem.

Angående kodeduplisering;

1.
Ville du også lagd en metode customer.IsReallyNotACustomer() ?

2.
Du har jo duplisert koden inni metodene IsSet og IsNotSetYet (selv om de tilsynelatende gjør motsatte ting)?

Vet du hvordan det virker i extension methods, kan man f.eks. skrive slik

public static bool IsNotSetYet(this object o)
{
return ! IsSet(o);
}

for å unngå kodeduplisering?

Vi er enige om at mye null i kode er en uting, som var budskapet mitt..

“En utvikler som ser koden din for første gang vil ikke nødvendigvis vite hva som skjer der”

Det gjør overhodet ingen ting. Som utviklere bør vi søke høyere abstraksjoner, og fjerne oss fra den implisite koden vi bedriver. Skriv kode som forteller “hva” og “hvorfor”, ikke “hvordan”. Når vi ser kode som i += 1; så tenker vi ikke på hvilke maskininstruksjoner som må til for å få til dette - vi har gått et steg videre. Og jo høyere abstraksjonsnivå vi kan tenke i, jo mer vil vi får gjort. Hvis jeg skriver kode som customer.IsReallyACustomer() så behøver ikke du å bry deg om at det er implementert som customer != null på nivået under. Ikke før du beveger deg ned på det nivået.., og da ser du det.

!= null er noe vi er vandt til, og derfor er det leselig, og vi ønsker å beholde det vandte og trygge. Men skal vi utvikle oss så må noe vike.

“Å ha både IsSet() og IsNotSetYet() er vel kodeduplisering?”

Ikke mer duplisering enn å ha både == og !=. I stedet for a!=b burde vi skrive !(a==b). Og hvorfor har vi både && og ||? Vi kan klare oss lenge med bare || og litt negering, kan vi ikke?

Ved å ha IsNotSetYet() så slipper jeg å skrive !o.IsSet(), som er helt uforståelig for alle andre enn dem som er vandt til et programmeringsspråk som benytter ! for negering. For ikke å snakke om hvor lett det er å overse det ene tegnet. Nei, den type duplisering, om du vil kalle det det, er jeg ikke redd for.

“Så hvor bør man plassere ObjectExtensions?”

Det er et viktig spørsmål. For tiden har jeg noen små “Marosoft.*” assemblies jeg referere overalt, som inneholder helt generiske ting - og slik jeg bruker dem passer ObjectExtensions inn der. Jeg ser på dem som en extension til System-namespacet.

Men jeg er usikker på om jeg vil bruke disse generiske IsSet og IsNotSetYet, eller om jeg vil lage mere domene-spesifike versjoner, og da plassere dem der hvor de hører hjemme.

Det Uncle Bob har å si om komponenter er utrolig spennende (ikke at jeg ikke sluker rått alt det andre han sier også).

Men:
Jeg vil argumentere for å ikke erstatte != null der hvor man faktisk trenger det, fordi dette er mer leselig. Ja, du leste riktig. MER leselig rett og slett fordi vi programmerere er så vante med å bruke det. En utvikler som ser koden din for første gang vil ikke nødvendigvis vite hva som skjer der, og da virker det mot sin hensikt.

Et spørsmål til koden din:
Å ha både IsSet() og IsNotSetYet() er vel kodeduplisering?

Så en kommentar til extension methods:
Utvidelsesmetoder er virkelig kraftige saker. På NDC nå kommenterte jo selveste Robert Martin at dette var nyttig i noen sammenhenger, men at det er lett å gå feil. For eksempel er det ekstremt viktig at man plasserer slike utvidelsesmetoder i riktige assemblies. Problemet blir jo at når man refererer et assembly som inneholder utvidelsesmetoder at det er lett å bli bundet opp til assembliet pga utvidelsesmetodene i assembliet og ikke pga det man egentlig trengte assembliet for. Så hvor bør man plassere ObjectExtensions? Sannsynligvis i en assembly som all koden din bruker uansett. Eller?