Jon*_*eet 10
对于小型工具,我很高兴拥有主类中的大部分或全部逻辑 - 通常可以使用较少的模型.(对于非常小的工具,我承认我通常不会对单元测试感到烦恼.特别是,在设计方面,如果你正在构建一个更大的应用程序中的组件,那么设计方面的好处就会少一些.)
对于大型应用程序,主要类别实际上只涉及设置和运行它们.如果您使用的是DI框架,那么代码确实非常少; 如果你没有使用依赖注入,那么主类通常充当"手动"依赖注入框架.
这不是一个类是否是"主类"的问题.这是public static void main(String args[])方法中有多少逻辑的问题.理想情况下,它应包含非常少的逻辑.它本质上应该构造一个或两个对象,然后在这些对象上调用方法.其中一个对象可能是this() - 主类的一个实例,这没关系.
你必须将main()方法放在某处 - 不需要创建一个特殊的类来保存该方法.
作为一般规则,尽量避免在静态方法中使用太多 - 静态方法不能被模拟用于测试.
主类中的逻辑是否应该最少，仅实例化其他专门类并从那里运行所有任务？
是。main方法及其周围的类在理想情况下应仅用作启动程序的入口。周围类的存在仅仅是Java程序组成方式的产物（所有内容都必须在某个类内），并且没有理由除了该main方法之外还应包含其他内容（但是绝对有理由说明为什么）不应该）。
当您将有趣的类（构成实际程序的类）分开时，就会为各种灵活性打开大门。也许其中一些类可以在其他一些项目中使用。也许有一天您会希望用更好的实现替换其中的一些。也许您会发现实例化所有这些类的更好顺序-因此只需交换几行。或者如何在并行线程中执行冗长的启动加载和实例化？只需将其中一些包装到合适的执行器即可。祝您有1000多行主课尝试这个。
这种灵活性对所有事物都至关重要，除了可能包含100行基本示例，原型等之外。但是，即使小型工具也趋于增长，为什么不从一开始就正确地进行开发呢？