Arguments and results

After returning from API Days in London, I’m studying design patterns for APIs. The last paper I read was “Arguments and Results” by James Noble (1), published in 1997 and still extremely relevant. Part of my current work, developing a data warehouse, is to optimize the transport of huge volumes of data. And if I want to use APIs, how can I do this efficiently? There is a consensus that REST API’s are not suitable in high-volume scenarios and studying this topic I arrived at Noble.

The article discusses patterns for object protocols and for this there are two groups:

  • How to send objects (Arguments): Arguments object, Selector object and Curried object
  • How to receive objects (Results): Result object, Future object and Lazy object


  • Arguments object: This pattern is utilised to streamline a method’s signature by consolidating common arguments and objects, and modifying the method signature to accept this consolidated object instead. It brings several advantages, you make your domain explicit; your customers can use what they have at hand (the objects, instead of separated values); and you are able to separate the processing logic from your business logic


    void Send-FixedIncome(EntityName, IssueDate, MaturityDate, PrincipalAmount, ...) { }


    void Send-FixedIncome(FixedIncome) { }

“adding an eleventh argument to a message with ten arguments is qualitatively quite different to adding a second argument to a unary message”

  • Selector object: When you have methods with quite similar arguments, this patterns introduces a selector that enables you to pick one of them. Noble mentioned you could a enum, maybe using GoF a Flyweight would do the trick.


    void CalculateHomeLoanAmount(HomeLoan, Collateral) { }
    void CalculateHomeLoanAmount(HomeLoan) { }
    void CalculateAutoLoanAmount(AutoLoan) { }
    void CalculatePersonalLoanAmount(PersonalLoan) { }


    void CalculateAmount(LoanType, Loan) { } //Loan would be the interface for all loan types

“Protocols (APIs) where many messages perform similar functions are often difficult to learn and to use, especially as the similarity is often not obvious from the protocol’s documentation”

  • Curried object: from the functional programming world, currying breaks a function with several arguments into smaller functions, where each one of those functions takes some (usually one) of the original arguments; these functions are called in sequence then. Noble introduces this pattern for a scenario where the caller should not need to supply all arguments (e.g. constants), the method can supply on their behalf. In GoF terms, it acts as a proxy.


    void SettleDebt(Loan, ParcelsToPay) { } # no. of parcels can be retrieved from the loan 


    int GetOpenParcels(Loan) { }
    void SettleDebt(Loan) { () => Settle(Loan) } # in Settle no. of parcels is retrieved

“These kinds of arguments increase the complexity of a protocol. The protocol will be difficult to learn, as programmers must work out which arguments must be changed, and which must remain constant.”

  • Results object: For complex scenatios, one might need several method calls to generate the expected result. Your results object should be a single one with everything on it. This pattern can be seen as the flip side of the Curried Object pattern. One aspect worth mentioning is when those several calls mean several systems. In this case. a result object helps to reduce the coupling and acts as an abstraction around them.

“Perhaps the computation returns more than on object”

  • Future object: This pattern is employed when we need to execute a time-consuming operation and perform other tasks while waiting for the operation to complete. In essence, we aim to process a result asynchronously and then likely invoke a callback upon completion.

” Sometimes you need to ask a question, then do something else while waiting for the answer to arrive”

  • Lazy object: Sometimes you need to supply a result, though it is not 100% sure whether the method will be called. The advantage of this is that we don’t get data unnecessarily.

“Some computations can best be performed immediately but the computation’s result may never be needed”

All in all, these concepts are quite widespread. Any mainstream programming language has support for async methods (Future object) and lazy evaluation (Lazy object). Moreover, good OO design makes ‘Arguments object’ and ‘Seletor object’ quite naturally appear. Even though it was a good back-to-basics article to remind me the importance of good design in my API methods.


CSS made easy

Damien Riehl is a technology lawyer and musician. And he doesn’t agree with copyright infringement lawsuits, for him music is mathematics. And if you remember that there are only 8 musical notes, Damien had the brilliant idea of making an algorithm that made all the combinations and put it in the public domain. According to him, this can help in those cases where someone is prosecuted just because they used a combination used by another, and the second person didn’t even know. See the faq at to understand better.

I’m not a lawyer, nor am I defending piracy, what caught my attention was the idea of noting that there is a finite space of possibilities. I think there is a fascination in being able to say ‘here’s everything about topic X’, personally that’s what attracted me to the master’s degree. I won’t be arrogant and say that I know everything about Design Thinking but I approached my studies with this objective.

Another topic: Think about the design of an HTML or SPA page, how many different ways are there to do it? We use CSS to control what is displayed. The colors are finite, ranging from #000000 to #FFFFFF; borders are top-bottom-left-right; and so on. Adam Wathan noticed this and developed TailwindCSS. With TailWind, you can write your CSS without leaving your HTML page. See the difference, before, if I wanted my text to be blue and bold, I would do this:


color: blue;
font-weight: bold;


<p class="info>
  Lorem Ipsum

And voilà, bold blue text. TailWindCSS allows you to write directly and it has a library with hundreds and hundreds of possibilities. As soon as you use it in your html, it automatically generates the CSS. This is a detail, an application runs in your terminal and scans your pages to know what to generate:


<p class="text-blue font-bold">
  Lorem Ipsum

or very large, bold, underlined, sky blue text centered on the page:

<p class="text-3xl font-bold underline text-sky-400 text-center">
  Lorem Ipsum

UnoCSS takes the idea further and eliminates the css file completely. In UnoCSS there is a script that analyses your pages at runtime and generates classes for you. And there is no need for an application running in the background. Magic! Note that the way of writing is exactly the same as TailWindCSS.


<p class="text-blue font-bold">
  Lorem Ipsum

I’ve been using UnoCSS a lot. But I have my criticisms, the large number of classes can make HTML code verbose, and it’s a fact, your HTML is difficult to understand. And the CSS generated by TailWindCSS is only readable by… TailWind developers 😀.

Additionally, the framework’s reliance on utility classes can lead to a lack of consistency in design across the site, as different people may use different classes to achieve similar effects. And since there is no CSS file maintained by the team, the need to document style choices is essential.

Still, the practicality seems to me to show that frameworks like these will be increasingly popular.