Maybe I see value in "isValidEmail()", "isValidPassword()", and "isEmailUnique()" and want to be able to somehow re-use them later.

Would it be a good design decision to create classes like:

- EmailValidator

- PasswordValidator

- UniquenessValidator

Yes, consider using JavaBeans , what you are doing is server side validation.
it would be better if you also do client side validation for that you will have to take a move to javascript or other client side scripting languages, server side and client side validation would be much better.

Originally Posted by DoubleDee

When a user registers on my website, one of the things I need to do is check to see if the Username already exists.

Should this just be a function (method) in a class, or can I break it out and make it its own class so that it can be re-used by others?

you can do it by executing some sql query against tables but my opinion is to use database side procedures or functions to handle this if your db supports it.

Maybe I see value in "isValidEmail()", "isValidPassword()", and "isEmailUnique()" and want to be able to somehow re-use them later.

Would it be a good design decision to create classes like:

- EmailValidator

- PasswordValidator

- UniquenessValidator

Debbie

'Good design decision' is hard to say. Personally, it sounds like you're on the edge of violating YAGNI

Don't get me wrong, there is certainly some value in stubbing all this stuff out, esp when it comes to unit testing but you just sort of get a feel for when and when not to do it based on experience.

Let's expand the design a bit. Say i want to have a registration service, but i don't know what is actually going to handle the authentication/authorization. I would stub all that out so i could pop in LDAP, some SSO Impl, a custom solution, whatever. I'm not 100% sure i would stub out a 'UniquenessValidator' If my password rules were that complex, i would maybe have a PasswordHelper class to delegate all that stuff to.

Email Validator is an interesting one because it's a more complex problem. How do you validate an email? You can half *** it with a regex, but you don't really know if an email has been validated until you send an email, and they send a response. You def wouldn't want that logic in your Service class.

A lot of people still feel that classes must be physical things and things which must be nouns.

I disagree, and from what I've read, more seasoned OO programmers disagree with that limited focus as well.

'Good design decision' is hard to say. Personally, it sounds like you're on the edge of violating YAGNI[/url]

How so?

If anything, a Registration class gets me criticized because it is not re-usable enough?! (Definitely not YAGNI material!)

Don't get me wrong, there is certainly some value in stubbing all this stuff out, esp when it comes to unit testing but you just sort of get a feel for when and when not to do it based on experience.

Let's expand the design a bit. Say i want to have a registration service...

I just appended "Service" to my class name because some people got hung up on the name "Registration" which they said is not a thing but an action or process. (In fact it is a noun and it is definitely an abstract "thing".)

, but i don't know what is actually going to handle the authentication/authorization. I would stub all that out so i could pop in LDAP, some SSO Impl, a custom solution, whatever.

You lost me.

I say "Registration" makes a logical class. Is it extensible, yes. Would I make it an interface or hope to re-use it all ver the place, no. I think it is a YAGNI.

I'm not 100% sure i would stub out a 'UniquenessValidator' If my password rules were that complex, i would maybe have a PasswordHelper class to delegate all that stuff to.

No, I was thinking maybe you could abstract a function that checks for unique values and turn it into a reusable class.

All I was saying is that for those who felt my Registration class was too UN-reusable and procedural, I could break out methods that could be re-usable classes if need be.

Email Validator is an interesting one because it's a more complex problem. How do you validate an email? You can half *** it with a regex, but you don't really know if an email has been validated until you send an email, and they send a response. You def wouldn't want that logic in your Service class.

Handling complex registration scenario

If you think that a process may be complex enough to have its own attributes, who said it cannot be made into a class? It makes perfect sense to do so.

As for the individual validators, I think that it depends on your own preference. For a banking software vendor I worked for in the past, they have specific validators for each type of data, like text, name, id, date, number, phone number and so forth. These validators are made into a generic library for use by other products in the same line.

If you are simply developing a small and simple application, I do not see the need to over complicate the application itself. Some practices may be good for large scale application development or streamlined application vendors may not be suitable for a small scaled and simple application.

When the programming world turns decent, the real world will turn upside down.