如何用Java组织类源代码?

如何用Java组织类源代码?,java,Java,到目前为止,我的平均类包含大约500行代码和大约50个方法。 IDE是Eclipse,我在其中启用了“保存操作”,以便按字母顺序对方法进行排序,首先是公共方法,然后是私有方法。 为了在代码中找到任何特定的方法,我使用“快速大纲”。如果需要,“Open Call Hierarchy”(打开调用层次结构)显示方法的顺序,因为它们逐个调用 这种方法具有以下优点: 我可以开始键入新方法,而不必考虑将其放在代码中的什么位置,因为保存后,Eclipse会自动将其放在适当的位置 我总是在代码的上半部分找到公

到目前为止,我的平均类包含大约500行代码和大约50个方法。 IDE是Eclipse,我在其中启用了“保存操作”,以便按字母顺序对方法进行排序,首先是公共方法,然后是私有方法。 为了在代码中找到任何特定的方法,我使用“快速大纲”。如果需要,“Open Call Hierarchy”(打开调用层次结构)显示方法的顺序,因为它们逐个调用

这种方法具有以下优点:

  • 我可以开始键入新方法,而不必考虑将其放在代码中的什么位置,因为保存后,Eclipse会自动将其放在适当的位置
  • 我总是在代码的上半部分找到公共方法(不必在整个类中搜索它们)
但也有一些缺点:

当将大型方法重构为小型方法时,我不太满意新的私有方法被放置在代码的不同部分,因此遵循代码概念有点困难。为了避免这种情况,我用一些奇怪的方式命名它们,使它们靠近每一个,例如:showPageFirst(),showPageSecond(),而不是showFirstPage(),showSecondPage()


可能有更好的方法吗?

组织您描述的方式听起来比我目前看到的99%的Java代码要好。但是,另一方面,请确保您的类不会增长太多,方法也不会太大


类通常应该少于1000行,方法应该少于150行。

好吧,给方法命名以便在IDE中更容易发现它们是不好的。他们的名字应该反映他们所做的事情,仅此而已

作为对您问题的回答,最好的办法可能是将您的类拆分为多个类,并隔离在每个类中具有共同点的方法组。例如,如果你有

public void largeMethodThatDoesSomething() {
 //do A
 //do B
 //do C
}
然后您对其进行了重构,以便:

public void largeMethodThatDoesSomething() {
 doA();
 doB();
 doC();
}

private void doA() {};
private void doB() {};
private void doC() {};

您可以创建一个名为SomethingDoer的类,在其中放置所有这4个方法,然后在原始类中使用该类的实例。

不要担心在类中对方法进行物理排序,如果看不到,只需使用Ctrl-O并开始键入方法名,然后直接跳到它

使用自描述方法名称比人为地命名它们以保持它们的字母顺序更容易维护代码


提示:学习快捷键可以提高工作效率

为用户组织代码。例如,库中的类可能具有以下受众:

  • 希望了解公共方法如何工作的更多细节的API客户机
  • 希望找到相关方法进行小改动的维护人员
  • 一个更认真的维护者,他想进行重要的重构或添加功能
  • 对于阅读源代码的客户机,您需要介绍核心概念。首先,我们有一个类doc注释,其中包括一个重要术语表和用法示例。然后是与一个术语相关的代码,然后是与另一个术语相关的代码,然后是与第三个术语相关的代码

    对于维护人员来说,任何一对可能必须一起更改的方法都应该在附近。一个公共方法和它的私有助手以及与之相关的任何常量应该一起显示

    这两组用户都通过将类成员分组到单独记录的逻辑部分来获得帮助

    例如,一个集合类可能有几个主要是正交的关注点,这些关注点不容易划分为单独的类,但可以划分为单独的部分

  • 突变子
  • 访问者
  • 迭代
  • 序列化和toString
  • 平等性、可比性、散列

  • 签出它将帮助您编写更易于维护和与他人共享的软件增加项目中的类的数量不是很好吗?我记得在Java教程中,他们警告不要随意增加类的数量,因为这可能会增加启动时间?是的,我知道你的意思,我也去过塔尔路。甚至还有一个Android开发(使用Java)的性能提示页面,简单的ole“告诉你不仅要创建几个类,还要避免使用有利于公共字段的方法,避免继承和多态调用,因为这会增加额外的纳秒延迟,在游戏循环中这些都是至关重要的。然而,如果使用这种方法走极端,将导致代码的笨拙和难以维护。根据您的程序业务需求,尝试使用单独的类作为方法正确、干净地编码。。。。。。然后,如有必要,对应用程序进行概要分析,查看是否有代码会产生性能瓶颈,并尝试只优化该部分,使其不那么美观,但对性能更友好。相信我,从头开始编码时只考虑性能,其他任何东西都不会给您带来麻烦。