匿名类与命名内部类?- 最佳实践?

2022-08-31 21:10:17

我有一个类,我们称之为LineGraph,它呈现一个折线图。我需要对它进行子类化,但派生类只在一个地方使用,并且与使用它的类耦合。所以我使用的是一个内部类。

我看到两种方法可以做到这一点:

匿名内部类

public class Gui {
    LineGraph graph = new LineGraph() {
        // extra functionality here.
    };
}

命名的内部类

public class Gui {
    MyLineGraph graph = new MyLineGraph();

    private class MyLineGraph extends LineGraph {
        // extra functionality here.
    }
}

我不是匿名内部课程的粉丝,因为坦率地说,我只是觉得它看起来非常丑陋。但是,对于只在一个地方使用的子类,命名的内部类是否过度了?什么是公认的做法?


答案 1

匿名内部类的一个优点是,没有人可以在其他任何地方使用它,而命名的内部类可以使用(如果设置为私有,则只能由创建它的类使用)。这是一个很小的区别,但它确实意味着你可以保护内部类不被意外地用于其他地方。

此外,使用匿名内部类会给任何阅读你的代码的人一个头 - “这个类只是在这里使用,而不是在其他地方使用。如果您看到一个命名的内部类,有人可能会认为它会在类的多个位置使用。

它们非常相似,所以这两点都不能改变游戏规则。我只是认为,如果您一次性使用匿名内部类,并在类中多次使用时命名内部类,则有助于澄清。


答案 2

(反驳丹尼尔·卢)

匿名内部类的一个缺点是,没有人可以在其他任何地方使用它,而命名的内部类可以使用(如果设置为私有,则只能由创建它的类使用)。这是一个很小的区别,但它确实意味着你可以帮助确保内部类不会意外地在其他地方重新创建。

此外,使用匿名内部类会给阅读代码的任何人带来困难,因为他们必须解析这个无处不在的类。使用命名的内部类,您可以更好地组织源代码。

我见过两个(或更多)匿名内部类具有完全相同代码的情况。特别是在GUI中(您可能有多个控件执行相同的操作),这可能会突然出现(我说的是生产代码,而不是我的学生编写的代码)。

可读性问题是双向的,有些人发现匿名内部类更好,因为它可以让你看到一个地方发生了什么,其他人发现它是一种分心。这部分归结为个人喜好。

此外,使类成为静态类更有效,如果您在实例中声明匿名内部类,那么将会有更多的开销,如果您不需要访问实例变量,那将是浪费的(但在它成为问题之前可能不值得担心)。

我个人更喜欢使用非匿名类,因为它们在以后修改代码时允许更大的灵活性。