A feature that often irks me in object-oriented code is the prevalence of useless
interfaces. Interface isn’t meant literally here: this applies to traits of Rust/Scala and protocols
of Clojure as well.
The advice of planning for the interface is just and solid, but people tend to follow this tip to
the extreme. It is not uncommon to see people design a module or class by defining its interface
first, with an actual implementation following later.
Scala gets lots of flak for implicits. Some of the feedback is justified: implicits in Scala can be
quite intimidating or confusing for beginners. That does not justify their dismissal, as implicits,
in all of their flavours, when used correctly, can be actually quite simple and powerful.
I recently had to do a refactoring for large program. The codebase was old, and wasn’t designed to
cope with the sort of change I was going to introduce, and I didn’t have much time either. Pressed
for time, but compelled by a modicum of professional pride, I didn’t want to half-ass the task by
adding jury-rigged solutions that would have left me feeling dirty and empty inside, at worst,
leaving a rotting mess to future developers—me.
Apache Camel is a routing and mediation engine. If that doesn’t say
anything to you, let’s try this: Camel lets you connect endpoints together. These endpoints can
vary. They can simple local components, like files, or external services like ActiveMQ or web
services. It has a common language format for the data, so that your data can be
protocol agnostic, and an intuitive DSL for specifying the connections and how the data should be
processed between messages.