Which is better Implementation approach - Create multiple objects or use a Utility class-CodePudding

I am working on a very high throughput REST service, which is required to handle huge scale (a few thousand requests per second). While trying to implement a feature, i created a class with required functions. It looked like this -

public class Sample {
    private SampleObject sampleObject;
    private SampleOther params;

    public Sample(final SampleObject sampleObject) {
        this.sampleObject = sampleObject;
    }

    public void process(){
        ...
        this.params = someComputation();
        this.processHelper();
        ...
    }

    private void processHelper(){
        ...
    }
}

You can assume there were a few other functions. Now a new instance of Sample had to be created for each incoming request that means a lot of objects will be created. My colleagues suggested it would be better to implement the class like a utility class with static methods and you can pass in parameters to avoid creating so many objects. Basically something like this -

public class Sample {
    
    public static void process(SampleObject sampleObject){
        ...
        processHelper(someComputation());
        ...
    }

    private void processHelper(SomeOther params){
        ...
    }
}

While both approach do the same work, i felt the first design was better. But in terms of performance and better resource utilization (less GC required etc), it seems 2nd approach is better. I'd like to hear different opinions on what should be done in such a scenario.

CodePudding user response：

If you put all static methods in a class then it becomes procedural programming model, that means by doing so you loose all the features of Object Oriented Programming model. We usually mark a method static when its implementation is pretty much standard and not expected to be altered by its subclasses. For business methods OOP approach is advisable.

CodePudding user response：

The biggest heap/GC cost is not the single per request object, but the multiple smaller objects that carry state between functions (Such as Someother params in the second example). Ditto for string objects, boxed number objects etc.

Avoiding the creation of 1 new object per request is just a reduction by 1 heap/GC object, Your first example seems to create 2 such outer objects (1 Sample and 1 SampleObject). In addition to the inner SampleOther object created by someComputation.

Ideally, a high speed implementation would have zero allocations per request, but would then need a longer-lived processing object per parallel processing thread, with each such object having room for the request parameters and calculation buffers. However that approach isn't very well suited to heavily object based runtimes such as Java and .NET, where the natural style is to receive all the request parameters as objects allocated by the network runtime, and the optimization potential is only to reduce the number of further objects allocated per request.