【问题标题】:How do you get rid of superfluous casts to implemented interface?你如何摆脱对实现接口的多余强制转换?
【发布时间】:2019-08-01 20:25:51
【问题描述】:

假设我有一个界面

public interface ICardSuit {
    /**short name*/
    public String getName();

    /** the colour of this card*/
    public ICardColour getColour();
}

我决定用枚举来实现:

public enum  CardSuit implements ICardSuit {
    HEART{
        @Override
        public ICardColour getColour() {
            return CardColour.RED;
        }
    },
    SPADE{
        @Override
        public ICardColour getColour() {
            return CardColour.BLACK;
        }
    },
    DIAMOND{
        @Override
        public ICardColour getColour() {
            return CardColour.RED;
        }
    },
    CLUBS {
        @Override
        public ICardColour getColour() {
            return CardColour.BLACK;
        }
    }
    ;

    @Override
    public String getName() {
        return this.name();
    }
}

我现在想测试它(使用 kotlintest,因为我越来越喜欢它):

class CardSuitTest : FunSpec(){
    init {
        test("there are exactly four suits"){CardSuit.values().size shouldBe 4}
        test("suits implement interface"){CardSuit.values().forEach { it shouldBe instanceOf(ICardSuit::class) }}
        test("suits have correct names"){
            val suits = CardSuit.values() as Array<out ICardSuit>
            suits.forEach { when(it.name){
                "HEART" -> it should beTheSameInstanceAs(CardSuit.HEART as ICardSuit)
                "SPADE" -> it should beTheSameInstanceAs(CardSuit.SPADE as ICardSuit)
                "DIAMOND" -> it should beTheSameInstanceAs(CardSuit.DIAMOND as ICardSuit)
                "CLUBS" -> it should beTheSameInstanceAs(CardSuit.CLUBS as ICardSuit)
            } }
        }
        test("suits have correct colours"){
            CardSuit.values().forEach { when(it){
                CardSuit.HEART,CardSuit.DIAMOND -> it.colour shouldBe CardColour.RED
                CardSuit.CLUBS, CardSuit.SPADE -> it.colour shouldBe CardColour.BLACK
            } }
        }
    }
}

我需要转换为ICardSuit,因为如果我不这样做,编译器会抱怨

None of the following functions can be called with the arguments supplied.

* T.should(Matcher<T>)   where T cannot be inferred for    infix fun <T> T.should(matcher: Matcher<T>): Unit defined in io.kotlintest.matchers

* ICardSuit.should((ICardSuit) → Unit)   where T = ICardSuit for    infix fun <T> T.should(matcher: (T) → Unit): Unit defined in io.kotlintest.matchers

我想保留as Array&lt;out ICardSuit&gt;,因为这是确保我只访问接口属性的最简单方法,

但我真的不喜欢强制转换我正在测试的实例。

我能做些什么吗?

【问题讨论】:

    标签: java kotlin junit type-inference kotlintest


    【解决方案1】:

    您是否有特定原因需要使用匹配器beSameInstanceAs

    你可以这样做:

    val suits = CardSuit.values() as Array<out ICardSuite>
    
    suits.forEach {
        when (it.name) {
            "HEART" -> it shouldBe CardSuit.HEART
            "SPADE" -> it shouldBe CardSuit.SPADE
       }
    }
    

    但是,如果你真的想使用beSameInstanceAs,你可以:

    suits.forEach {
        when(it.name) {
           "HEART" -> it shouldBeSameInstanceAs CardSuit.HEART
           "SPADE" -> it shouldBeSameInstanceAs CardSuit.SPADE
        }
    }
    

    我并没有真正从编译器那里得到任何抱怨

    【讨论】:

      【解决方案2】:

      beTheSameInstanceAs(CardSuit.HEART) 返回一个Matcher&lt;CardSuit&gt;,所以它不能匹配任意的ICardSuit。这是有道理的(尽管Matcher 可能是 contra 变体,但您需要在这里使用协方差)。但是你可以:

      1. 明确调用beTheSameInstanceAs&lt;ICardSuit&gt;(CardSuit.HEART)

      2. 创建辅助函数

        inline fun <T1, reified T2 : T1> Matcher<T2>.widen() = object : Matcher<T1>() {
            override fun test(value: T1) = 
                if (value is T2) 
                    this.test(value) 
                else 
                    Result(false, "$value is not a ${T2::class.name}", "$value is a ${T2::class.name}")
        }
        

        并调用

        it should beTheSameInstanceAs(CardSuit.HEART).widen()
        

        (我认为类型推断应该在这里起作用)。

      3. 因为beTheSameInstanceAs(x) 真的可以匹配任何东西,所以声明一个返回Matcher&lt;Any&gt; 的等效函数:

        fun beTheSameInstanceAsAny(x: Any) = beTheSameInstanceAs(x)
        
        // usage
        "HEART" -> it should beTheSameInstanceAsAny(CardSuit.HEART)
        

      【讨论】:

      • 我认为不需要所有这些。在下面查看我的答案
      • 赞成。我认为这个答案对于解释代码无法编译的原因仍然很有用,并且解决方法在其他类似情况下也很有用。
      猜你喜欢
      • 2015-04-11
      • 2012-04-15
      • 2011-08-21
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-10-19
      • 2011-06-07
      相关资源
      最近更新 更多