I was recently thrown into a Java web application project, and Ive come across a number of classes that follow this type of format:public class MyThingy {   private final int p1;   private final String p2;      public MyThingy (int p1, String p2, ) {      this.p1 = p1;      this.p2 = p2;         }   public static void doSomething(int p1, String p2, ) throws Throwable     {      final MyThingy myThingy = new MyThingy(p1, p2, );      myThingy.execute();   }   private void execute() throws Throwable {      //do stuff    }}It seems like this could be accomplished with the following code, which to me seems way easier to read.public class MyThingy {   public static void doSomething (int p1, String p2, ) throws Throwable {      //do stuff    }}The only possible benefit I can see from doing it the first way, is that if you had to break up execute() into smaller pieces, they could all share the initial parameters without having to explicitly pass them around.  But this maybe only benefits the lazy coder, as it becomes difficult for the reader to tell which methods need which parameters and when the values might be changed (akin to global variables.)Is there something I'm missing? Threading, performance?Edit:I should have mentioned, although the constructor is public, it is not called.  The only usage is like this:MyThingy.doSomething(p1, p2...);Aside from this in itself being problematic for testing, I can't see any reason not to put the logic of execute() directly into doSomething().  Even if we were to get rid of the static function, the constructor still doesn't make sense to me; I think the parameters should be passed directly to the method that will use them.
Is this code structure beneficial in any way?
java;coding style
I think your intuition on this issue is right.What we have here is a plain (in this case, static) method whose implementation has been broken up into a class.The method as a class technique reduces the number of variables you have to explicitly pass around, while in fact obscuring how data flows using what are, in spirit, global variables.None of this is actually in the spirit of OO, since the instance is throwaway and its state is ephemeral.And yet, this is a common pattern, especially in introductory Java books and may have been on the minds of Java designers (who introduced lots of ways to declare classes, seemingly to aid this usage).So, should you use it?Sure, sometimes.In fact, at issue is not just pure methods as classes. In normal classes, you may be tempted to create fields that don't hold state in-between invocations of public methods. They're used only to avoid passing parameters between private methods. In the past, I tried to avoid it at all cost, but then realized that long parameter lists suck too.I try to avoid pure method classes as I think they come with a lot of mental baggage (so much potential potential). (I also lean against disposable fields in regular classes.) But if there's a ton of variables to pass around, the win in code cleanliness may be worth it.I try to use classes when there is a point to it, and in fact it's usually easy to imagine one. Perhaps in the future you'll extend the class with additional implementations. Perhaps the instance can be thought of as a function object that you'd want to initialize and pass around. And then, the class is no longer a pseudo-OO method class.