tags:

views:

162

answers:

6

Hi,

I am writing a set of classes: RAR, ZIP and Trip. They all share a common interest: they are archive formats. So, I initially thought about doing this:

1) Write a base abstract class

abstract class Archive {}

and place it at "libraries/archive/archive.php".

2) Write zip, rar and trip classes

class Archive_Zip extends Archive {}

and place them at "libraries/archive/zip.php"

3) Access the specific class (e.g. the Zip) like this

$this->archive->zip->...

This was my initial approach. However, do you think this is a good approach? Should I even abstract them at the first place? What are the pros and cons of just writing a "libraries/zip.php" file (and all others separately)?

Do you have any suggestions or arguments against my approach? Is there something bad I have done?

+1  A: 

Since #3 doesn't really follow from #1 or #2 an alternative approach is just to instantiate the object when you need it.. like this:

$archive = new Archive_Zip();

Done. No need to complicate it more than necessary.

Allain Lalonde
+1  A: 

The main benefit of an abstract class is a common interface that you can use throughout your code. You will then be able to switch the implementation to another archive format without changing a bunch of code. I have not used PHP a lot, so this answer is based on general OOP principles. It would seem like achives would be a good candidate for the approach since they share a common set of operations.

Mark Goddard
A: 

Personally I have not had much use for abstract classes. At best, they seem to be a check on your own code, ensuring you have defined a set of methods within your subclass.

Inheritance itself will do you well, and it will help to have a base Archive class if there are a number of methods common to your subclasses.

Adam Backstrom
+1  A: 

It depends on your implementation. Will you use a Strategy pattern to determine which compression algorithm to use? If the compression algorithms could be used interchangeably among other bits of code, abstract them.

Should they adhere to the same contract and share common functionality? Probably. This is a good use of abstraction.

Also, if it just helps you create a logical association for the sake of readability, go for it. That's my take on it.

Kevin Swiber
+2  A: 

I like Zend Framework approach.

Files:

lib/Archive.php
lib/Archive/Zip.php
lib/Archive/Rar.php

Code:

require_once 'Archive_Zip';
$zip = new Zip();

See this: http://framework.zend.com/manual/en/coding-standard.naming-conventions.html#coding-standard.naming-conventions.classes

eipipuz
What about "$zip = new Archive_Zip;" and no need to include anything (lazy loaded automatically)?
rFactor
A: 

The great thing about having an Archive base class, in this problem, is it should really guide you to define a set of public methods for client code to manipulate archive files, without regard to the archive format. (The other way to do the same thing would be to define an Archive interface, which all your other classes implement. But I suspect you'll end up with some common code in all of the classes; having Archive as your base class gives you a good place to put that.)

grantwparks