```abstract class MemoryCache lt T gt private val cachedValue = AtomicReference lt T gt fun getOrEmpty Maybe lt T gt = Maybe fromCallable cachedValue get fun set value T this cachedValue set value fun invalidate cachedValue set null ``` This class has concrete methods

abstract class MemoryCache<T> {

    private val cachedValue = AtomicReference<T>()

    fun getOrEmpty(): Maybe<T> = Maybe.fromCallable { cachedValue.get() }

    fun set(value: T) {
        this.cachedValue.set(value)
    }

    fun invalidate() {
        cachedValue.set(null)
    }
}

This class has concrete methods

Mike

12/11/2019, 3:46 PM

In this case, it's referring to the second recommendation.

Abstract classes which do not define any
abstract
members should instead be refactored into concrete classes.

👍 1

If you made it abstract because you don't want it instantiated directly, but it is used as a parent class, then add an

@Suppress("UnnecessaryAbstractClass")

to the class, and Detekt will not report that issue.

Eugen Martynov

12/11/2019, 4:26 PM

It is exactly abstract because I don’t want to instantiate it

thanks

I probably will disable this rule at all

yousefa2

12/11/2019, 4:53 PM

Why not use an interface with default implementations?

👍 1

Mike

12/11/2019, 6:02 PM

That's also a good suggestion. If you're on JDK8, don't forget to add the @JvmDefault annotation to it, too, so that the compiler will generated the bytecode.

➕ 2

6 Views