Think back to the last time you looked at an unfamiliar block of code. Did you immediately understand what it was doing? If not, you’re not alone – many software developers, including myself, find it challenging to grasp unfamiliar code quickly…
I would argue that the validate routines be their own classes; ie UserInputValidator, UserPasswordValidator, etc.
I wouldn’t. Not from this example anyway. YAGNI is an important paradigm and introducing plenty of classes upfront to implement trivial checks is overengineering typical for Java and the reason I don’t like it.
Edit: Your naming convention isn’t the best either. I’d expect UserInputValidator to validate user input, maybe sanitize it for a database query, but not necessarily an existence check as in the example.
I wouldn’t. Not from this example anyway. YAGNI is an important paradigm and introducing plenty of classes upfront to implement trivial checks is overengineering…
Classes, functions, methods… pick your poison. The point is to encapsulate your logic in a way that is easy to understand. Lumping all of the validation logic into one monolithic block of code (be it a single class, function, or methods) is not self-documenting. Whereas separating the concerns makes it easier to read and keep your focus without mixing purposes. I’m very-engineering (imo) would be something akin to creating micro services to send data in and get a response back.
Edit: Your naming convention isn’t the best either. I’d expect UserInputValidator to validate user input, maybe sanitize it for a database query, but not necessarily an existence check as in the example.
If you go back to my example, you’ll notice there is a UserUniqueValidator, which is meant to check for existence of a user.
And if you expect a validator to do sanitation, then your expectations are wrong. A validator validates, and a sanitizer sanitizes. Not both.
For the uninitiated, this is called Separation of Concerns. The idea is to do one thing and do it well, and then compose these things together to make your program — like an orchestra.
If you go back to my example, you’ll notice there is a UserUniqueValidator, which is meant to check for existence of a user.
Oops, right, I just glanced over the code and obviously missed the text and code had different class names. Another smell in my opinion, choosing class names that only differ in the middle. Easily missed and confusion caused.
I don’t think our opinions are too far off though. You’re just scaling the validation logic to realistic levels and I warn that in practice coders extrapolate too quickly and too often, which results in too much generic code which is naturally harder to understand and maintain than specific code.
This is abuse of the separation of concerns concepts IMO. You have taken things far too far many made it far less readable overall. The main concern here is password validation - and the code already separated this out from other code. By separating out each check you are just violating another principal - locality of behavior which says related things should be located close to each other. This makes things far easier to read and see what is actually going on without needing to jump through several classes/functions of abstraction.
We need to stop trying to break everything down into the smallest possibly chunks we can. It is fine for a few lines of related code to live in the same function.
I wouldn’t. Not from this example anyway. YAGNI is an important paradigm and introducing plenty of classes upfront to implement trivial checks is overengineering typical for Java and the reason I don’t like it.
Edit: Your naming convention isn’t the best either. I’d expect
UserInputValidatorto validate user input, maybe sanitize it for a database query, but not necessarily an existence check as in the example.Classes, functions, methods… pick your poison. The point is to encapsulate your logic in a way that is easy to understand. Lumping all of the validation logic into one monolithic block of code (be it a single class, function, or methods) is not self-documenting. Whereas separating the concerns makes it easier to read and keep your focus without mixing purposes. I’m very-engineering (imo) would be something akin to creating micro services to send data in and get a response back.
If you go back to my example, you’ll notice there is a
UserUniqueValidator, which is meant to check for existence of a user.And if you expect a validator to do sanitation, then your expectations are wrong. A validator validates, and a sanitizer sanitizes. Not both.
For the uninitiated, this is called Separation of Concerns. The idea is to do one thing and do it well, and then compose these things together to make your program — like an orchestra.
Oops, right, I just glanced over the code and obviously missed the text and code had different class names. Another smell in my opinion, choosing class names that only differ in the middle. Easily missed and confusion caused.
I don’t think our opinions are too far off though. You’re just scaling the validation logic to realistic levels and I warn that in practice coders extrapolate too quickly and too often, which results in too much generic code which is naturally harder to understand and maintain than specific code.
This is abuse of the separation of concerns concepts IMO. You have taken things far too far many made it far less readable overall. The main concern here is password validation - and the code already separated this out from other code. By separating out each check you are just violating another principal - locality of behavior which says related things should be located close to each other. This makes things far easier to read and see what is actually going on without needing to jump through several classes/functions of abstraction.
We need to stop trying to break everything down into the smallest possibly chunks we can. It is fine for a few lines of related code to live in the same function.