Class method naming convention

[captainccs]

It seems that the general practice is to name class methods as "getters" and "setters" where a getter retrieves stuff from an object and a setter adds something to an object.

I'm working on a Files class and I'm getting a bit confused. I can get file objects from HTML forms, from the file systems, from a database or I can create one with a php script but when I get them I actually set them in the file object. Also, when I get file info from a file object it is for the purpose of "setting" it elsewhere, say a download to a browser or attach to an email.

How do you resolve this mess?

[oddz]

Getter and setter methods don't add anything to a object. They create a way for the outside world to change and retrieve information - normally a property of a object.

Seems like what you need is one generic file class with the appropriate properties of a file - whatever they might be. You could also consider using a interface to make the system more scalable.

I guess the question to ask is the specific attributes and responsibilities that make up the File class. Before you ever begin writting the class you should have a good understanding of what properties and methods are going to exist and the purpose of the class. You may find out that you need more then one class to handle all the things you need to do or that the approach you were thinking about won't work under the circumstances.

Right now everything just seems ambiguous and to actually give you any help you will need to work out these details.

[captainccs]

Getter and setter methods don't add anything to a object. They create a way for the outside world to change and retrieve information - normally a property of a object.

Believe it or not, this is what I meant to say. I guess I wasn't too clear

Seems like what you need is one generic file class with the appropriate properties of a file - whatever they might be. You could also consider using a interface to make the system more scalable.

I guess the question to ask is the specific attributes and responsibilities that make up the File class. Before you ever begin writting the class you should have a good understanding of what properties and methods are going to exist and the purpose of the class. You may find out that you need more then one class to handle all the things you need to do or that the approach you were thinking about won't work under the circumstances.

Right now everything just seems ambiguous and to actually give you any help you will need to work out these details.

I've been using a File class with two sub-classes (image and attachment) for some time now but as I'm upgrading my skills to php5 I figured it was time to upgrade my Files classes also.

I'm pretty clear what I want the class to do:

1. upload files from HTML forms
2. save files to the file system
3. save files to a database
4. display images on web pages
5. download files
6. attach files to emai
7. some other services like listing the files

I have code that does this but not neatly tucked into my Files class. To upload a file to a database I want to use two methods:

processIncomingFile()
if no errors,
saveFileToDatabase()

to download a file I want to use two methods:
getFileFromDatabase()
downloadFileToBrowser()

to show an image on a web page I want to use two methods:
getImageFromDatabase()
displayImage()

My question is how would you name these methods to fit in with the getter/setter nomenclature?

[World Wide Weird]

I would make a very generic base File class and extend it to account for non-File-ish behavior, e.g., with an Image class, Attachment class, etc. In the case of inserting the file into a database, it seems that the object would be rather more a database field than a file, the latter of which, by definition, resides on a filesystem. Once you do that, as oddz said, the nomenclature should become more clear.

[oddz]

Well those seem like methods that have a specific responsibility not getter and setters for a property. It may be worth while to use a interface in this instance. Seems like you have the methods together to do so and using interfaces would offer increased flexibility without using inheritance.

interface IUpload {
  public function processIncomingFile();
  public function saveFileToDatabase();
}

interface IDownload {
  public function getFileFromDatabase();
  public function downloadFileToBrowser();
}

interface IDisplay {
  public function getImageFromDatabase();
  public function displayImage();
}

Now if something is only able to be downloaded you just have that class implement IDwonload. However, if something is able to downloaded, uploaded and displayed you can just as easily implement all three.

class Movie implements IUpload,IDisplay {

  public function processIncomingFile() { }

  public function saveFileToDatabase() { }

  public function getImageFromDatabase() { }

  public function displayImage() { }

}

class Resume implements IUpload,IDownload,IDisplay {

  public function processIncomingFile() { }

  public function saveFileToDatabase() { }

  public function getImageFromDatabase() { }

  public function displayImage() { }

}

At the same time you could create a abstract class that implements all three and defines a common implementation. Then if you needed to you could override specific methods in sub classes to change the implementation. However, regardless of what you do they will all look the same and be able to be used the same way.

abstract class File implements IUpload,IDownload,IDisplay {

  public function processIncomingFile() { }

  public function saveFileToDatabase() { }

  public function getFileFromDatabase() { }

  public function downloadFileToBrowser() { }

  public function getImageFromDatabase() { }

  public function displayImage() { }

}

[captainccs]

... In the case of inserting the file into a database, it seems that the object would be rather more a database field than a file, the latter of which, by definition, resides on a filesystem.

I visualize a "file" as a container with some data in it and some external markings to tell other objects how to deal with it. One of those objects could be a file system but it can also be a server, or an email client, or an HTML form.

The external markings (properties) would be file size, file type, file name and in some cases width and height and some others.

[captainccs]

... It may be worth while to use a interface in this instance. Seems like you have the methods together to do so and using interfaces would offer increased flexibility without using inheritance.

Thanks! I'm going to have to take a closer look at "interfaces."

[World Wide Weird]

The external markings (properties) would be file size, file type, file name...

Yes.

...and in some cases width and height and some others.

Namely, in the case of an image, video, Flash movie, etc. That's why I would make these child classes of the base File class. You might additionally want to add crop(), resize(), rotate(), etc., to your Image class. A Video class would have properties like bitrate, duration, etc. You really don't want to clutter up a File class with all that stuff. They would be nonsensical in the context of treating the object purely as a file. You may even choose not to place such objects in the File inheritance chain, but rather pass a File object to an Image or Video object's constructor instead.

My example of the Attachment class would make sense in the context of a mail system object model. The Attachment might have properties that only apply to a File when attached to an e-mail but not otherwise.

[captainccs]

Namely, in the case of an image, video, Flash movie, etc. That's why I would make these child classes of the base File class. You might additionally want to add crop(), resize(), rotate(), etc., to your Image class. A Video class would have properties like bitrate, duration, etc. You really don't want to clutter up a File class with all that stuff. They would be nonsensical in the context of treating the object purely as a file. You may even choose not to place such objects in the File inheritance chain, but rather pass a File object to an Image or Video object's constructor instead.

That's an interesting thought! I now have an Image sub class and I don't really work with movies and stuff but should I expand in this area, I'll keep it in mind.

My example of the Attachment class would make sense in the context of a mail system object model. The Attachment might have properties that only apply to a File when attached to an e-mail but not otherwise.

I also had an Attachment sub-class but all it did was to format the file properly for my mailer code (not yet OOP). I was wondering if that merited a sub-class at all.

[World Wide Weird]

I also had an Attachment sub-class but all it did was to format the file properly for my mailer code (not yet OOP). I was wondering if that merited a sub-class at all.

Good point. There may indeed be cases where you don't feel that some modest amount of functionality warrants writing an entire class. Richard Heyes' awesome htmlMimeMail5 class (now part of PEAR, I think) simply has an add_attachment() method that does the transfer encoding and what-not.