Polylith interfaces: why the duplication of interface declarations?

[jgomo3]

Update: I think I get the idea…

The interface is dynamically checked by the tool. A consequence of this technique is that we don’t have to maintain an static file declaring the “form” of the interface. The tool will collect all the “implementations” and check conformance.

It is like if in the Java world, we could omit the interface files, and a tool collect all the classes declaring they are implementing it, build and the “interface” for us before passing it to the compiler, so in theory we don’ t have to “maintain” that interface file ourselves.

I think I see the value here. Am I gaslighting myself here?

I leave my original quetioning/rant of how interfaces are “duplicated” in the codebase.

I can’t seem to be able to pass this part of the poly tool tutorial about declaring the same interface in multiple components.

In particular.

”””
Because we are free to edit the interface.clj file for both user and admin, they can get out of sync if we are not careful. Luckily, the poly tool will help us keep them consistent and complain if they differ when we run the check, info or test commands:
”””

It is of little consolation that the poly tool can help us in that case. It just feels very brittle.

I can’t get how this is preferred over something like the Java interfaces, where you define the interface in 1 single place, and implement it in multiple places. Isn’t Clojure Java interoperable already? so why was not used the at hand solution (Java Interfaces) to this problem?

How can I justify this to people in order for them to invest their time exploring Polylith?

The justification so far is that it is an agnostic Software Architecture worthy of studying, and that that particular way of declaring the usage of an interface by the duplication of declarations is just a particularity of how Polylith has been used in Clojure while using the poly tool, but you are not enforced to do it that way (but you would have to write your own tools and documentation about how you are “implementing” Polylith).

But… I’m not even sure about this. Is the Polylith Architecture prescribing this duplication of interfaces declaration in General (independently of the language)?

[p-himik]

I don’t use Polylith myself but I think your analogy with omitting interface is correct.

Apart from that, working with Java is just clunky. It’s alright when you have to use Java from Clojure, apart from some very niche things, but writing Java and than consuming it from Clojure is not that smooth due to the need of recompilation. Of course, there’s also definterface but it’s not a complete replacement for Java interfaces and you can’t redefine it partially. So if you have a set of plain Clojure functions, you can just redefine a single one and not touch the rest, and it will work fine if you know how to work with the REPL properly. But with interfaces, you have to replace the whole thing and make sure that all the previous usages of it are also refreshed, which potentially involves state, so it might be easier to just restart the whole thing. Which is not REPL-friendly at all.

[seancorfield]

We have a large Polylith codebase at work – 150k lines of Clojure.

Where we have multiple implementations of a Polylith component, the interface nses are different in content: they have the same functions, with the same arguments etc, but the implementations are different – not all of them delegate to an impl ns function, some throw exceptions, some are implemented inline (remember: you don’t have to have a separate impl ns).

Multiple implementations are fairly rare. It isn’t like runtime polymorphism – it’s a “build-time” selection of the implementation, so it’s fairly specialized, IMO. We have about 200 bricks and the most components with multiple implementations was just 3 of those. Now we only have one component with multiple implementations (an i18n component that has one implementation based on our database and another implementation based on JSON files, intended as part of a small “preview” app our UI/UX guy can use when editing our Selmer HTML templates).