3 ms·
What would piss me off to no end in this Scala codebase I used to work on was the creation of traits that were then only extended by one object: trait Foo {
by mruts 8y ago
What would piss me off to no end in this Scala codebase I used to work on was the creation of traits that were then only extended by one object:
trait Foo {
val x = 1
}
object FooObj extends Foo
So pointless and unnecessary. And before anyone says this is just planning for the future, the future can go fuck itself.
- seanmcdirmid 8y agoRather than planning for the future, this is usually an artifact of problem solving and designing in the language (they don’t know only one Foo is needed when they are planning out what a Foo should do).
- zoul 8y agoThat makes sense if you can then write code using that trait as a more general type. http://degoes.net/articles/insufficiently-polymorphic http://degoes.net/articles/insufficiently-polymorphic
- dtech 8y agoThere's two valid use cases for this: 1. Testing. The trait makes it easier to mock a dependency. In this case the second implementation is in the testing codebase. 2. Quick overview and contract. If you have a `trait DoThing { def firstThis() def thenThis() }` it very clearly shows what the trait is meant to do with what contract, even if the actual implementation is 500 LOC with 15 private methods.
- xchaotic 8y agoIt is this way for large projects. You write your function, the interface is tested, but the whole project becomes a big bloated mess. I don't think there's any better way to write large projects. Instead consider loosely coupled smaller projects. Perhaps this only moves the complexity elsewhere and you have a dependency hell, but arguably the same can be said for versioning parts of code.