How to avoid static methods?

Suppose there is a class which is very often used.
I mean a class such as Validator.
Almost every methods of every classes needs the parameter to be validated first.
And, I think using static methods on Validator class make sense.
But, I know it’s bad since it’s global state and hard to test.

Then, I’m thinking about instantiating the validator in almost every methods of every classes
But, I think it’s not a nice solution.

And, I also think if the validation doesn’t need to be inside the method of the model class.
Instead, I think using the validator class when it’s passed as an argument such as $model->do($validator->validate($name, ‘string’))
But, then I think the validation is a must so it must be placed in the methods of model class.

Is using static methods okay ?
Is there any better solution ?

Why is there no replies to this topic? Is my question not clear ?

I’d say, in the overall picture of OOP and testable code, static methods don’t jive well. Here is a SE post I found that hits on the reasoning. The better solution is dependency injection.

Scott

I think passing a validator instance as a constructor argument is the best option the vast majority of the time. I would need a very good reason to deviate from that, and I don’t know your code well enough to say whether it would be OK in this situation.

In the link you give, he said that static methods are fine when they’re utility methods.
Is validator utility method ? (The validator will validate input and throw exception if validation failed.)

And, you say it’s better to use dependency injection. But, injecting the validator to almost all classes via constructor injection is such a pain, isn’t it? (Because most of classes will use this validator class).
I imagine if I have to new DB($dbconfig, Validator $validator), new User($id, $name, Validator $validator), new Post($id, $body, Validator $validator), and I think it’ll be not nice.

Validation is more a layer (with two to three different kinds too, like form, data and route validation).

Most frameworks use the DiC for validation and thus, they make validation a service. If you find the injection a pain, then make the object a service with a DiC and let the DiC resolve the dependency.

And this kind of issue is what makes frameworks so applicable. They’ve already solved a ton of the issues you are now running into. Now that you are running into them, you can start to understand the direction frameworks took and either use that direction yourself (as in use the framework or its components) or reinvent the wheel yourself. The latter is fine for learning, but at one point you’ll go “gee, they’ve already done that too” and you’ll start to appreciate the value of a framework or its components.

The Symfony Validation Service
(A) Laravel Validation Service (example)

Scott

1 Like

It’s probably for this reason that frameworks tend to treat entity objects (such as User or Post) as plain old data. You can set any values you want into them, then later some validation service checks whether those objects actually hold valid data, that way they don’t all require the validator.

1 Like

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.