Question

我经常发现自己这样编程：

public class SomeClass implements SomeInterface
{
  private someData;
   public SomeClass(Parameters And Stuff)
   {
   }

   private void a()
   {
     e();
     f();
     g();
   }

   private void b()
   {
     h();
     i();
   }

   private void c()
   {
     j();
   }

private void d()
{
   ...
   might call even more private methods...
}

private void e()
{
   ...
   might call even more private methods...
}

private void g()
{
   ...
   might call even more private methods...
}
.......
private void j()
{
   ...
   might call even more private methods...
}

   @Override
   public void interfaceMethod(Some Parameters)
   {
     a();
     b();
     c();
     d();

   }
}

真正的方法名称是有意义的，并且具有返回值和参数。

但问题是，用户调用的方法只有一个或几个，这很好，但是，为了保持实现的清洁，我将其分解为许多私有方法。

这是个好主意吗？如果其他人查看我的代码，除非他们遵循执行跟踪，否则可能会有点混乱？

这种编程风格是否可以接受？是否有更清晰明智的方式来应对这种情况？

由于

Answer 1

这实际上归结为编码风格，而不是任何硬性规则。

这种方法的问题是问自己：

代码是否可重复使用 - 如果是这样，它将成为一个好方法
代码是否很长 - 如果是这样我应该考虑将其拆分
通过拆分代码可以使代码更具可读性 - 如果是这样，我应该考虑拆分代码。

另一方面虽然：

代码是否无法重复使用？如果我只是从一个地方打电话，是否值得将它作为一种方法？
这种方法是否微不足道，是否真的值得单独使用，还是应该合并为另一种？
将代码制作者分离得更清楚/更清晰 - 或者实际上合并它会更简单吗？

判断对这些问题进行加权的正确方法是将经验丰富的程序员与干净的架构与新手程序员区分开来。不幸的是，我不能给你一个快速而快速的答案，因为它更像艺术而不是科学。

Answer 2

只要方法名称具有适当的描述性，这是一个很好的做法。

Answer 3

这种做法比其反向（1000行方法）好10倍。只需确保遵守DRY原则，并留意代码中的对象可以使生活更轻松的区域。您通常可以通过标记传递给方法的参数数量或传递给多个方法的相同参数来识别这些区域。这是一个明确的指示器，需要一个类实例变量或对象。

Bob Martin的书“清洁代码”的另一个引用是：

第一条规则是方法应该很小。第二个规则是方法应该小于那个。

Answer 4

关闭课程是一个很好的做法，每次你创建其中一个私有方法时，你的方法名称给这条线提供了一个意义，有一些注意事项：

总是喜欢简短的方法（在java中超过10或15行很大）
更加努力地找到能够引导代码读者的真正好名字，kent beck经常说“意图揭示”这些名字。当你认为自己的名字很好时，请休息一下，再读一遍你的代码，找到更好的名字：P（在软件设计中找到最好的名字，也许是最重要的名字）。
尝试遵循罗伯特·马丁的“报纸比喻”，干净的代码是每个软件开发人员必备的书。
有时，如果您有很多私人方法，请考虑单一责任，也许您会发现这个班级可以分成小班。

代码组织有很多私有方法？

4 个答案: