Functions and Classes

[Debbie Dawson]

Can something that is basically a function be a class?

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?


Debbie

[David Newton]

Depends, but either way, it's going to be in a class: where it fits best depends on the rest of the app. As long as it's grouped in a way that makes sense given the rest of your architecture it doesn't really matter *where* it is. To me it sounds like part of a user service.

[Debbie Dawson]

David Newton wrote:Depends, but either way, it's going to be in a class: where it fits best depends on the rest of the app. As long as it's grouped in a way that makes sense given the rest of your architecture it doesn't really matter *where* it is. To me it sounds like part of a user service.

The context of my question is this...

Let's say I decide that I need a "RegistrationSevice" class. (I think that is somewhat in line with what you'd approve, at least as far as the class name.)

And this class needs to do the following things to register a user...

- checkRequiredFieldsComplete()
- isValidEmail()
- isValidPassword()
- doEmailsMatch()
- doPasswordsMatch()
- isEmailUnique()

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

[David Newton]

You know there's no one right answer to questions like this, right? "Good" is subjective and depends on opinions as well as good practices.

Would *I* creates classes like those? Most likely not, but I might have an "EmailUtils" or "EmailValidatonUtils" and a similar class for passwords. But it depends: I could easily see some email validation stuff being required throughout an application, for example to validate the email in a "email this story to a friend" scenario.

It's less likely I'd ever need to do password stuff anywhere else but in user registration/modification flows, though. I might, however, have a need to implement different levels of password security, though: normal users might be able to get away with eight characters and a single digit, whereas an administrative/system user might require stronger passwords--having this functionality injectable in some way would allow for different implementations to be used under different circumstances.

I still get the feeling you're trying to get everything perfect the first time around: this almost never, ever happens.

[Debbie Dawson]

David Newton wrote:You know there's no one right answer to questions like this, right? "Good" is subjective and depends on opinions as well as good practices.

Yes, but Titanic solutions (e.g. let's make all variables global) tend to be pretty consistent and I'm trying to avoid those.

Would *I* creates classes like those? Most likely not, but I might have an "EmailUtils" or "EmailValidatonUtils" and a similar class for passwords. But it depends: I could easily see some email validation stuff being required throughout an application, for example to validate the email in a "email this story to a friend" scenario.

It's less likely I'd ever need to do password stuff anywhere else but in user registration/modification flows, though. I might, however, have a need to implement different levels of password security, though: normal users might be able to get away with eight characters and a single digit, whereas an administrative/system user might require stronger passwords--having this functionality injectable in some way would allow for different implementations to be used under different circumstances.

Okay, but help me to understand this...

I seem to keep getting yo-yo'd between "put it all in one class" and "your classes must be tiny creatures with very specialized code.

I was all excited that I decided to break out the Registration and Authentication logic from my User class and I had someone tell me that the aforementioned methods where too much for one class called Authentication?! :cry: (Something about "single purpose" classes?)

I'm trying to strike a balance between "God Classes" and a billion little classes.

Personally I'm not so concerned that classes are "reusable" as they logically represent ONE THING.

(I read some article that was Agile based that said, "Don't go out of your way trying to build reusable classes because they likely don't exist...")

My current mindset is to break up my e-commerce site into logical blocks that represent real-world things, and them link them together. This is where I'm getting really confused!! (Things like Registration, Authentication, PageNavigator, Product, ProductDetails, User, ShoppingCart, Gallery, etc seem to me to be decent "candidate classes".)

I still get the feeling you're trying to get everything perfect the first time around: this almost never, ever happens.

Not as much as that as making fatal mistakes in the beginning and then having to throw everything away and start over.

I've seen too many people dive into building things with any kind of structure, outline, or plan (e.g. Term Papers, Vacations, Job Searches, College Degrees, Databases, Applications, Home Additions, Government) and then end up wasting an enormous amount of Time, $$$, and Resources.

I'm all for "refactoring", but you can't really refactor a pile of crap, right?! :wink:

(If someone would write a book that took OOP theory and applied it to real-world problems I might be farther ahead. But even my Head First books still take a rather academic approach to teaching things... *sigh*)

I'm not sure why I'm struggling so much with OOP, but I'm just not truly getting how you go from a Class to numerous Classes that talk to each other and get something done in a working System. There just seems like a million ways to approach things and I have yet to have anyone really do a good job explaining a good way to see things. (By contrast, I "get" database modeling and it seems very natural to me.) I dunno...



Debbie

[David Newton]

There are a lot of good ways to see things. There are innumerable ways to tie things together.

You're in a very early stage of learning how to do things--who cares if you have to throw everything away? (And you wouldn't anyway--even the worst pile is usually a matter of re-structuring rather than wholesale destruction.)

Stop over-analyzing. Go make some mistakes.

(And there are all sorts of resources that discuss OOD--not sure why you can't find any. But I wouldn't worry much yet, either.)

[Debbie Dawson]

David Newton wrote:There are a lot of good ways to see things. There are innumerable ways to tie things together.

That can be overwhelming for a beginner on any topic.

You're in a very early stage of learning how to do things--who cares if you have to throw everything away? (And you wouldn't anyway--even the worst pile is usually a matter of re-structuring rather than wholesale destruction.)

I care, because I'd like to get things done before I'm 50...

Stop over-analyzing. Go make some mistakes.

Just trying to point my skis before I leap over the mountain edge...

(And there are all sorts of resources that discuss OOD--not sure why you can't find any. But I wouldn't worry much yet, either.)

I didn't say I couldn't find any resources.

I said that they had limited utility.

If you want to learn how to drive like Mario Andretti, ditch the books on driving and the driving instructor and go find Mario, yah know?! :wink:



Debbie

[Jimmy Clark]

Debbie, Object technology and Object-Oriented software design is a skill that typically requires at least 2 to 3 years of study and practice in order to become proficient. Even then, there is no guarantee that an individual will be able to create efficient designs. It is a certain way of thinking. And is simply a design technique. As mentioned, there can be thousands of different ways to create a particular design. Many of them can be very good. Some of them can be medicore. Some of them can be horrible, but still work. And finally some of them can be total crap.

I would suggest that you read the following to get an understanding of the basics. The author presents Object technology in a basic, easy-to-understand style to a non-technical audience.

Good luck!

Object Technology: A Manager's Guide
by David A. Taylor, Ph.D.

Paperback: 224 pages
Publisher: Addison-Wesley Professional; 2nd edition
Language: English
ISBN-10: 0201309947
ISBN-13: 978-0201309942

[David Newton]

Debbie Dawson wrote:I care, because I'd like to get things done before I'm 50...

You'll learn faster by doing, and making mistakes.

And to repeat something I said in your previous thread: you're talking about an app of a few hundred, *maybe* a thousand lines of code. It's a learning project. It doesn't matter one iota if you have to throw it away and start over. I'd recommend *purposefully* throwing it away and starting over, making some different decisions, and see what happens. Then throw *that* away and do it all again.

That's the *only* way you're going to get the experience and knowledge you want. You can read all you want--and your book-fu will be strong. But unless you get in the trenches and actually *do* something, *make* some mistakes, and *learn* from them, all the book knowledge in the world isn't helpful.

Good luck.

[Debbie Dawson]

David Newton wrote:You'll learn faster by doing, and making mistakes.

But unless you get in the trenches and actually *do* something, *make* some mistakes, and *learn* from them, all the book knowledge in the world isn't helpful.

Good luck.

So if I go off and write some code - in PHP - for my registration process and post it here, will you look at it and try to help me improve it?

(Java is not an option this go-round, but my design questions transcend any language...)



Debbie

[David Newton]

I'm sure plenty of folks would jump in with their two cents worth once there's something to see.

[Tim Holloway]

I should point out that "Plan one to throw away" was one of the precepts in Fred Brook's seminal book "The Mythical Man-Month". I also know that it's fairly rare for people to actually do that. It's emotionally unappealing to go to some effort and then chuck it all, so people are more likely to attempt to "fix" things. Which sometimes works, sometimes doesn't.

In Java, there's a very common precedent for a one-shot class. JSF validators are normally classes containing a single method in them. A JSF validator is a plug-replaceable stateless component, so there's really nothing else you can do with it for the most part.

[David Newton]

One-method classes are common in anonymous classes, too; it really just depends on the context.