Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
I agree with you that it's a design choice, not bad practice.
On his side, he's using polymorphism to decide which validation to use. He violates the single responsibility principle though. The foo container now contains the foo, and validates it.
You're adhering to the SRP with a dedicated foo validation class. I assume the problem your colleague has with this is that it validates all kinds of foo, so it'll need to look up the validation based on the foo provided.
A third option would be to have a foo validator implementation for each kind of foo, and have it as a field in the container. The container would then have a validate method that delegates to its validator.
Related Rants
Java Joke......
(Warning, wall of text)
Settle an argument for me. Say you have a system that deals with proprietary .foo files. And there are multiple versions of foo files. And your system has to identify which version of foo you are using and validate the data accordingly.
Now the project I was on had a FooValidator class that would take a foo file, validate the data and either throw an error or send the data on its merry way through the rest of the system. A coworker of mine argued that this was terrible practice because all of the foo container classes should just contain a validate method. I argued that it was a design choice and not bad practice just different practice. But I have also read that rather than a design choice that having a FooValidator is the right way to do OOP. Opinions?
undefined
oop
design patterns