A question about design

MelodyMaker

Sorry if I bother you with this, but I'm a OOP newbie and I would like to know your opinion about that.

I'm developing a site which requires registration and where users can upload their fotos. The question is this:

I created a user class

class User{
private $username;
private $email;
private $country;
???private $photos= Array();???
...
function __construct($idUser)
//here I load the details about the user;
}

Now, every user can upload at most 12 photos, which can have a small caption.
So, the question:

1) Do I need a "Photo" Class? (the encapsulation principle tells me so)
In this case what is the best way to associate this class to the user class? By storing the photo objects in an array property of the user class? And where should I put the method "loadPhotos"? In the user or in the photo class?

class Photo(){
private $url;
private $caption;

function __construct($IDPhoto){
.... here another select on the same table, mmm
}
}

...but if I do this, there will be two SELECT : One to get the user's ID photo and the other to retrieve photo's data. Or I'm wrong..?

2) Storing all the data about photos in an array (as a property) and forget about Photo class?

I'm a bit confused, sorry.

Thank you very much in advance.

Davide

laserlight

1) Do I need a "Photo" Class? (the encapsulation principle tells me so)

Besides encapsulation, abstraction comes into play. As such, the question is: do you need to model a photo, or is a photo just say, a string, so you can make do without further abstraction?

In this case what is the best way to associate this class to the user class? By storing the photo objects in an array property of the user class?

Yes, that should be fine.

And where should I put the method "loadPhotos"? In the user or in the photo class?

Each Photo object is constructed with the relevant data, so it does not make sense to provide "load photos" functionality with it (rather, you just "load" one photo). As such, the function should go in the User class, perhaps in its constructor.

...but if I do this, there will be two SELECT : One to get the user's ID photo and the other to retrieve photo's data. Or I'm wrong..?

Consequently, only one database query is needed.

MelodyMaker

Thank you Laserlight!

The fact is that Photo Class should only have a url, a caption, and (I think) a reference to the user (idUser). So, I'm not sure if I have to model this, or simply call a method in my user class that fills i.e an array with the photo data.
But let's suppose that I also have to delete a photo. Or add (upload) a photo
Then, there will be two other user methods called deletePhoto and addPhoto.

My problem is that I just can't decide what is the best solution...

NogDog

My inclination would be to have a Photo class since (a) there are multiple properties associate with it, and (b) it allows you to use type-hinting when adding a photo to a User object.

MelodyMaker

Thanks for your suggestion.
There's particularly a point that is making me crazy and that's about how a new Photo should be created:

I need a method to get all the user photo. I put that method in the user class (is this correct??):

function getPhotos(){

SELECT * from userphoto where idUser = ...

//at this point, I have to build the object photo, but how?
while ($res = $result->fetch_array()){
//here I can get the IDPhoto, since i retrieve it from the DB (the link (url) to the foto is in the DB and the file has uploaded)
$photo = new Photo ($res['IDPhoto'] $res[url], $res['caption'])
//
}

IDPhoto is a primary key in the userphoto table
if upload is a method of the Photo class, how can I use it, since there can't be a Photo yet?
By using upload as a static method?

BUT, for example, when a user, uploads a photo (if the upload has success) the photo can't have a IDPhoto,
because it gets (or should get) that ID ONLY after a successful update AND after an INSERT into a DB.
So, a constructor like this:

new Photo ($IDPhoto,$url, $caption)

in the case of an upload does not work, I think.

It is this that is making me crazy...