Should validation classes be static classes?

I am working on a system that receives thousands of requests per second, and essentially one of the tasks we are trying to avoid is to create unnecessary / additional objects .

We need to check the incoming request for 6 query elements per se.

I am thinking of creating a class for each element check.

However, I am trying to justify whether to use static validation classes against an object with instances containing HttpRequest as the instance field.

Should I use static classes or objects? what would you do?

Essentially, what I'm doing is injecting List<IValidator> validators to query the handler and iterate over it. but not sure if I should have an instance against static classes.

+4
source share
2 answers

Have you really measured the effect that new Validator instances have on memory and static method reuse? The cost of using a short-lived facility is very, very small. You should measure the difference between the two approaches, and if there is no measurable difference, use the one where the code is cleaner and more understandable.

In such cases, it always makes sense to measure the difference, rather than simply suggesting that one is better than the other.

+4
source

In multi-threaded environments, using static classes / methods always opens concurrency traps. Since creating and assembling short-lived objects is cheap, it is often better to create short-circuit objects than working with cuncurrency problems and additional synchronization, which is expensive.

Struts has switched from static request handlers to instance-based request handlers for the same reasons.

+1
source

All Articles