My first time OOP and I don't even know where to start

[jmayoff]

I know PHP and I've read and watched a number of OOP tutorials.  I have a basic sense of how to do an OO web app, but I don't really have any idea about the nitty-gritty or where to start.  My first project is a freelance-type web site where clients post jobs and freelancers bid on them.  I think I'll start small and work on only one aspect, say the client end of it. 

 

My thoughts are that I would create the following classes:

 

-ClassUser

-ClassClient (which would extend ClassUser)

-ClassGig

-ClassDatabase

 

Now, starting with ClassUser, I'm trying to come up with the methods I'd need.  I'm thinking something like these:

-create

-login

-logout

 

Is that the level at which the methods should be, or should I have the following methods instead of function create().

-showUserTheForm

-getUserInfo

-validateUserEmail

-validateUserPassword

-requiredFieldsFilled

-putUserInfoInDB

-sendUserWelcomeEmail

etc...

 

As you can see, I'm a real noob at this, so any help would be greatly appreciated.

[KevinM1]

IMO, user creation should be separate from a user class.  It just has the potential to get too complicated if a user class is designed to both create users and model an individual user's info.  Remember two things - the currency of OOP is the OBJECT, and K.I.S.S.  It's okay (and more often than not, preferred) to have many small, singular purpose objects than large, complicated objects that try to do too much. 

 

Similarly, why should a user be bothered with form creation and validation?  How does form handling tie into what a user is, logicality speaking?  (hint: it doesn't)

 

Some questions you should answer:

 

What's the difference between a user and a client or a freelancer?  How would you represent these differences in code?

What's required to create a user, client, or freelancer? 

How flexible does your form validation need to be?  What inputs are you expecting to use?  What does 'valid' mean in those cases?

 

Answering these questions will inform your design.  They may not bring you to the most efficient or elegant solution, but it will get you started.

[roopurt18]

IMO, user creation should be separate from a user class.  It just has the potential to get too complicated if a user class is designed to both create users and model an individual user's info. 

 

Why?  The user object should have properties that I can set, either directly or via getters and setters.

 

When I call $user->save() it should internally do the following:

1) Perform a check that the current $user object is valid.  All required fields are there.  All formatting requirements are met.

2) Determine if this is a user that exists in the database.  Doesn't exist?  Insert.  Exists and was loaded from the database? Update.  Exists and we didn't expect it to?  Throw an exception.

[KevinM1]

IMO, user creation should be separate from a user class.  It just has the potential to get too complicated if a user class is designed to both create users and model an individual user's info. 

 

Why?  The user object should have properties that I can set, either directly or via getters and setters.

 

When I call $user->save() it should internally do the following:

1) Perform a check that the current $user object is valid.  All required fields are there.  All formatting requirements are met.

2) Determine if this is a user that exists in the database.  Doesn't exist?  Insert.  Exists and was loaded from the database? Update.  Exists and we didn't expect it to?  Throw an exception.

 

Yeah, I wasn't really clear with what I meant.

 

The 'creation' I referenced above was meant as the mechanism which obtains the registration form data, filters/validates it, then creates a User object from that data.

[roopurt18]

Got it.

 

What I would do in that regard, and I have yet to work this into any of my own projects because I don't really use the M in MVC, is to create a generic form class.  In addition, each model should have some sort of interface to the form class so the form class can query the fields and the types of inputs necessary for them.

 

Then creating new user form should be as simple as:

<?php
$user = new User();
if( count( $_POST ) ) {
    $user->fromPOST();
    if( $user->save() ) {
      header('Location: success.php');
      exit();
    }
}
$form = new GenericForm( $user );
echo $form;
?>

 

It may not be setup exactly like that, but I know if I had a site with lots of models and forms I'd want a simple mechanism to create the interface for CRUD operations.