性能:内部接口与单独的接口类

时间:2018-07-22 18:06:19

标签: java methods interface

在我的android项目中,我在4个不同的Recyclerviews中使用了4个Activities,并且我需要3个方法onClickonButtonClickonDeleteClick。使用了一些方法,而没有使用。首先,我在需要的每个interface中创建了一个内部Activity,并为他们提供了适当的方法。但是因为它们在重复,所以我用所有3种方法创建了一个单独的interface类,然后在我的4个Activities中引用了它。我覆盖了我需要的方法和我不需要的方法,我只是空着身体。最佳/首选方式是什么?

1。

public class A {
                private OnItemClickListener mListener;

                public interface OnItemClickListener {
                    void onDeleteClick(int position);
                }

                ...
                @Override
            public void onDeleteClick(int position) {
                errase(position);
            }
}

2。

public interface OnItemClickListener {
        void onItemClick (int position);
        void onDeleteClick (int position);
        void onButtonClick (int position);
    }

public class A {
     private OnItemClickListener mListener;

     ...
     @Override
            public void onItemClick(int position) {
                 //empty because I dont need it here
            }

            @Override
            public void onButtonClick(int position) {
                 //empty because I dont need it here
            }

            @Override
            public void onDeleteClick(int position) {
                errase(position);
            }
}

2 个答案:

答案 0 :(得分:1)

您可以创建一个适配器类,并为接口中声明的所有方法提供空的实现,这将减少重复的代码行,然后对其进行扩展。 (尽管不确定这是否是Java 8或更高版本的最佳方法) 在您的代码中有点像

interface OnItemClickListener {
    void onItemClick(int position);
    void onDeleteClick(int position);
    void onButtonClick(int position);
}

abstract class Adapter implements OnItemClickListener {
    public void onItemClick(int position) {};
    public void onDeleteClick(int position) {};
    public void onButtonClick(int position) {};

}

public class A extends Adapter
{
    @Override
    public void onDeleteClick(int position) {
        errase(position);
    }
}

答案 1 :(得分:0)

在我看来,没有“最佳/首选”方式:

  1. 由于嵌套的接口不是隐式的内部(它们是隐式的静态),因此没有对封闭类实例的隐藏引用。因此,普通接口和嵌套接口之间的性能应该为零

  2. Java样式指南不会/不会推荐一种形式作为通用声明。

  3. 我还没有听说有人试图对此进行科学的可用性研究。

  4. 我还没有听说过有人试图科学地评估开发人员对此的看法。

  5. 这给我们留下了“随机StackOverflow贡献者的见解”,我对此不信任。 (每个人在阅读代码时的心理过程都不相同...)

底线:什么都没有。


在实际情况下,您可以自行决定哪个 更具可读性/可维护性。但是:

  • 我建议您选择一致。

  • 如果您的API可能会被其他人使用/维护,最好与他们讨论。与同事达成共识将是一件好事,甚至是“同意不同意”,然后继续前进。

但是不要挂在嘴上,因为这绝对是一个问题。