På jobbet har det varit mycket diskussioner kring APIer på sistone och eftersom jag i och med det har ämnet på läppen tänkte jag lobba lite för en grej som jag tycker är fräck. Även om implementationen av det jag tänker på är i Java så borde konceptet vara applicerbart i vilket objektorienterat språk som helst. Here goes.

Föreställ dig att du som utvecklare arbetar mot ett API – låt oss kalla APIet för AnimalRepository – där metoden nedan är definierad:

Animal findAnimal(int id);

Föga förvånande syftar metoden till att slå upp ett visst objekt av typen Animal. Men vad händer om det inte finns något objekt som matchar det id man skickar in? Det står klart att det inte går att utläsa genom att bara titta på metodsignaturen. Som utvecklare får man då helt enkelt jaga fatt i dokumentationen och/eller gräva runt i källkoden för att förstå denna hantering, eftersom den kan se ut på lite olika sätt från API till API.

En vanlig förekommande design är att metoden helt enkelt returnerar null om det inte finns något resultat. Men null är problematiskt på så många sätt – det har skrivits spaltmeter om eländet och första bästa resultat när jag googlade kan man titta på här. En annan lösning som jag själv inte har testat men läst en del om är Null Object pattern. Grejen här är att man knackar ihop en implementation av typen som inte har något beteende. Men hur skulle det te sig? Ska man då kolla om objektet är tomt? Att metoden kan returnera tomma objekt framgår i vilket fall inte av dess signatur. En tredje möjlighet (som känns ganska knäpp) vore att kasta ett exception. Men en enkel fråga borde man väl ändå få ställa utan att världen går under? Exceptions är ju mer ”woop woop, hördu det brinner här borta”.

Nej det här blev omständigt. Vore det inte bättre om metodsignaturen helt enkelt kunde kommunicera hur man hanterar ett icke-resultat? Kan designern av APIet göra något här? Såklart han kan, varför skulle jag annars bemöda mig med att problematisera så pass? 🙂 Säg hej till Google Guava!

Man kan tycka vad man vill om Google men de har gjort en hel del bra grejer och Guava är en av dem. Guava är en samling utilities för Javautvecklare som hjälper oss i vår vardag. Här finns massor av matnyttigt (som det finns anledning att återvända till i ett framtida inlägg) men det jag vill lyfta fram i detta nu är något som kallas för Optional. Och varför inte börja med ett exempel? Vi tar samma metodsignatur som ovan fast med en ny twist:

Optional<Animal> findAnimal(int id);

Optional kan ses som en wrapper för saker som kan vara null. Och bara genom att använda det i metodsignaturen klargör vi för den som ska använda APIet att här kan det minsann returneras något som inte är något alls. Här har vi alltså ett enkelt och kraftfullt koncept som gör att koden nu kommunicerar bättre än tidigare. Men hur använder man sig av returvärdet? Det är ett ganska snyggt upplägg om jag får tycka till:

Optional<Animal> result = animalRepository.findAnimal(123);
if (result.isPresent()) {
  // we have a result
  Animal animal = result.get();
  ...
}

Kod som kommunicerar är fina grejer! 🙂 Det var allt för denna gången. Trevlig helg!