Boards
anyone here any good at object-oriented programming?
I'm having trouble with the basic concepts. I'm making an image gallery.
I'm going to want a method which uploads a new image to the filesystem and stores the image's details in a database 'images' table.
Now, should this method be part of the gallery class (gallery->addnewimage) or part of the image class (image->createnewimage)?
Perhaps it should be a combination of both?
Maybe the gallery object calls its 'addnewimage' method which in turn instantiates a new image object and calls the various methods involved in uploading, resizing and finding a home for our new image...
I dunno. Anyone?
What are you writing this in?
You kind of need both methods anyway because you shouldn't assume that all Image objects will be in your Gallery object, I would think.
So I'd have said you need to be able to add images as part of the Image object and then you need to add Image objects to the Gallery as part of the Gallery object.
But it'll probably be different depending on what sort of thing you're writing. I use PHP 5 at lot a the moment but its Object Orientated stuff isn't that good so often the choice is moot.
NERRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRD
Thanks.
I'm using PHP5. In this design ALL images will belong to a gallery, so I guess i'll want to have this as a method of the image class.
gallery class, even.
Okay in PHP I generally have one class for each database table
not including linking tables between the two.
I separate from there to make maintenance easier so that in my control panel I have a screen for each table.
Hence if I was doing what you're talking about I'd have a table for Gallery data and a table for Image data and I would have methods to insert for each kept separate.
The code to link gallery data with the image data could go in either but it would probably be in the Image class.
In my case, because all tables needed a fairly basic system of access I actually greated a bass class from which all table classes are derived, including some abstract methods that have to be defined for each class to allow for the different table fields.
That said, doing everything from the Gallery is fine but it seems counter-intuitive to me since it requires that you have your gallery before you have your image - what if you want to upload images and then assign them to different galleries after?
That's exactly how I'm doing this.
As for your final point, I allow for moving images to other galleries in the 'edit image' console. Since the only thing which ties an image to a gallery is a field in the image table ('galleryID'/'belongs_to' or whatever) it's fairly easy to output a list of all existing galleries and, if the image is to be moved, just update the images table with the new gallery ID.
You should really use a linking table.
One with a key of gallery_id and image_id combined. This will let you put images in multiple galleries and mean you could introduce an extra field in the linking table if you needed to differentiate things at all, maybe.
It's better for database normalisation if you do this sort of thing. Then you'd select your gallery from a drop down and use a table with checkboxes and thumbnails to add or remove images from the gallery. Right now it sounds like you have to edit each image in turn to move it between galleries which will probably prove irritating.
That said there's a lot to be said for a drop down on image creation / check box selection so you can choose the galleries when you upload.
in a general sense i agree with you.
However, this particular site is an artist's portfolio site.
It makes more sense to me to create a project/gallery (say 'sculptures april 2009') and then, UI-wise, add images to that project/gallery.
It's unlikely that images will need to be moved around from project to project that much (apart from in the case of accidental upload) so a big table solution for image editing like you suggested would most probably be redundant.
Thanks for your help though, it's much appreciated.
Sounds like you've got it sorted then, to me.
Simpler the better. :-)
I've got a couple of years experience with Java.
What language you using?
I have no idea what your design should look like.
There's no right answer to these things.
createnewimage probably should not be a method of Image unless it's a static factory method or something. You could have a static factory method that returns an Image instance else you could create your Image instances directly.
Gallery could have some sort of images collection like Gallery.Images and you could add images like Gallery.Images.Add(new Image()) (assuming it's Java/C# type thing.
A good book on OO design patterns and OO design generally - "Head First Design patterns" it's an easy read and it has a fit girl on the cover.
I'm trying to find the hidden insults there.
I'm not sure there are any.
Are you feeling okay?
see above
I appreciate that there's no 'right answer'
but I've been writing PHP for yonks and have only just found the time to get into the OOP side of it.I know php isn't the best language for it but I figured it'd be easier for me to learn OOP concepts if i was already fluent with the language. I've been recommended that book before, I'll check it out. Thanks.
i get paid to do it but i dont claim to be good
it should be in the gallery class. the easiest way to think of it is in terms of reuse. ie. an image requires an image to be an image
the gallery is a collection of image objects. so an image will have the propertys size, name, file path.
so in gallery you'd have
addNewImageToGallery(string GalleryName, int size, string name, string filpath)
{
new image(size, name, filepath)
}
and in image you'd have the upload on the constructor or construct it with one of those no image uploaded images and expose the a upload image method you can call from the gallery class.
or somthing like that.
opps
MyImageClass myimage = new MyImageClass(size, name, filepath)
instead
yeah, that's the conclusion I was coming to.
thanks!
: )
no probs
:)
What those above have said
and for the love of god, please use camelCase... so much easier to read!!!
haha, i do.
just didn't bother for the thread.
Yeah in PHP
camelCase of the objects and methods, underscores as spaces and all lower case for instance variables and the like.
ohTheo
I dunno the technical names, like.
I don't have to use them in my job.
Yeah leave the technical names for the nerds
right?
Like you?
I hope so.
aside (sorry)
I'm not daft enough to claim that HTML/CSS is programming, but I riff off the idea of dabbling with summats.
But know little about it.
Are PHP & MySQL worth a squirt?
If so, is say Larry Ullman's PHP & MySQL Visual QuickPro book as good as it's rep? (as a follow on to Elizabeth Castro's (X)HTML & CSS book from the same series).
Or is python (or something else) or something else worth meddling with instead?
At the mo, it's just for the lulz, but you never know.
Yours enquiringly,
TheWza
I learned from a different book the name of which escapes me.
It was old, though. You want to make sure whatever book you get covers PHP 5.
PHP & MySQL make website design quite powerful, assuming you have something that needs them.
I've got one eye on
migrating from/supplementing my eBay shop.
I've yet to properly get the HTML/CSS side locked down, but, yeah, as I understand it, the php/MySQL could be useful for doing ecommerce shizzle.
Yeah it would be.
Worth investigating existing e-commerce solutions as security will be your biggest issue. Look for free e-shop things and check the reviews since it's likely someone else already did the hard work for you.
Not that there's any harm in doing it yourself if you're just using Paypal for all the sensitive credit card and address type details, I would think.
I did this most recently:
http://pocuswhiteface.com
and it was actually a lot of fun.
OSCommerce is defacto php store
.
for html/css I'd recommend the tutorials at http://www.htmldog.com
for php I'd recommend the O'Reilly book 'Programming PHP'
not sure about the best resource for leaning mysql.
personally id put the effort into learning ASP.NET and sql server
its more advanced but looks better job wise
.
I'm not really on a mission, jobs-wise but cheers for the heads up on that front.