One of the items of feedback I got from the article about interface immutability is that it did not give any concrete feedback for how to design interfaces. Given that they are forever, it would be good to have some sort of guidance.
The first item is that you want something that uses the implementation, as well as several distinct implementations. However, this item is too obvious: in almost all cases I have seen in the wild of a bad interface, this guideline was followed.
It was also followed in all cases of a good interface.
I think this guideline is covered well enough that by the time anyone designs a real interface, they understand that. Why am I mentioning this guideline at all, then?
Because I think it is important for the context of the guideline that I do think actually distinguishes good interfaces from bad interfaces. It is almost identical to the non-criterion above!
The real guideline is: something that uses the implementation, as well as several distinct implementations that do not share a superclass (other than object or whatever is in the top of the hierarchy).
This simple addition, preventing the implementations from sharing a superclass, is surprisingly powerful. It means each implementation has to implement the "boring" parts by hand. This will immediately cause pressure to avoid "boring" parts, and instead put them in a wrapper, or in the interface user.
Otherwise, the most common failure mode is that the implementations are all basic variants on what is mostly the "big superclass".
In my experience, just the constraint on not having a "helper superclass" puts appropriate pressure on interfaces to be good.
(Thanks to Tom Most for his encouragement to write this, and the feedback on an earlier draft. Any mistakes that remain are my responsibility.)
Interfaces are forever
(The following talks about zope.interface interfaces, but applies equally well to Java interfaces, Go interfaces, and probably other similar constructs.)
When we write a function, we can sometimes change it in backwards-compatible ways. For example, we can loosen the type of a variable. We can restrict the type of …read more
Analyzing the Stack Overflow Survey
I am the parent of two young kids. It is easy to sink into random stuff, and not follow up on goals. Strict time management and prioritization means I get to work on open source projects, write programming books and update my blog with a decent cadence. Since a lot …read more
Publishing a Book with Sphinx
A Local LRU Cache
"It is a truth universally acknowledged, that a shared state in possession of mutability, must be in want of a bug." -- with apologies to Jane Austen
As Ms. Austen, and Henrik Eichenhardt, taught us, shared mutable state is the root of all evil.
Yet, the official documentation of functools tells …read more
Don't Make It Callable
There is a lot of code that overloads the
This is the method that
an object activates:
something(x, y, z)
something.__call__(x, y, z)
is a member of a Python-defined class.
At first, like every operator overload, this seems like a …read more
Staying Safe with Open Source
A couple of months ago, a successful attack against the Node ecosystem resulted in stealing an undisclosed amount of bitcoins from CoPay wallets.
The technical flow of the attack is well-summarized by the NPM blog post. Quick summary:
- nodemon, a popular way to run Node applications, depends on event-stream.
- The …
Checking in JSON
JSON is a useful format. It might not be ideal for hand-editing, but it does have the benefit that it can be hand-edited, and it is easy enough to manipulate programmatically.
For this reason, it is likely that at some point or another, checking in a JSON file into your …read more
If you want to speak to me, 1-on-1, about anything, I want to be able to help. I am a busy person. I have commitments. But I will make the time to talk to you.
- I want to help.
- I think I'll enjoy it. I like talking to people …