PHP Class modeling issue - php

Question

I've written a few classes and have come to a fork in the road about what I should do. My base question is, how do I avoid duplicating my code across classes with very similar functionality? Traits are not an option for me right now, and I don't think they would help too much here anyway.
I have the following classes implemented.
//either a directory or a file on the file system
class FileSystem_Object{
//the size of the class in bytes
public function getSize(){}
//same as phps native realpath
public function getRealPath(){}
}
//a zip file on the file system, e.g. files that end in .zip extension.
class FileSystem_Object_Zip extends FileSystem_Object{
//returns size of all files if they were to be uncompressed, in bytes
public function getUncompressedSize(){}
}
//a singleton file that keeps track of only one object copy of a file
class FileSystem_Manager{}
These classes sortof provide me with some SPLFileObject type functionality. I can do the following kind of stuff
$object =
FileSystem_Manager::getInstance()
->getFileSystemObjecT( '/some/path/to/file/or/directory/' );
Every time I call the getFileSystemObject method it will either return a new class object or return an object that was assigned to that path already, thus avoiding me creating multiple objects that point to the same path on the filesystem. ( maybe not the best idea but that's what I went with. )
Here's where we get to the issue a bit.
I have another set of classes that I use to 'lock' objects. Right now the only objects that I'm locking are filesystem_objects, regardless of whether they're directories or files. This works simply enough by creating a lock file for the file based on the process id of the php process trying to lock it.
inteface Lockable_Object{
public functon getLockableIdentifier();
}
class Lockable_FileSystemObject implements Lockable_Object{
/**
* I return a false here if the file doesn't exist
* so any other processes trying to lock this file will
* know they can no longer lock it because it has moved
* or been renamed for some reason.
*/
public functon getLockableIdentifier(){
if( file_exists( $this->_fullFilePath ) ){
return $this->getRealPath();
}
return false;
}
}
The problem I face now is that I'd like to create a Zip file object that can be locked as well, and I'd like to be able to lock pretty much any file/directory but I DON'T want to have to duplicate code. Which of the following should I do
//Option 1
class Lockable_Object_Zip extends FileSystem_Object_Zip
implements Lockable_Object{
//In here I would have to duplicate the getLockableIdentifier method and do that
//for every file type i decide to make in the future
}
//Option 2
class Lockable_Object_Zip extends Lockable_FileSystemObject
//In here I would have to duplicate all the zip functionality coded into
//FileSystem_Object_Zip
}
//Option 3
class FileSystem_Object implements Lockable_Object{
//build in the 'lockablity' into the base class
}
Right now I'm leaning towards option 3 but the only reason I would not like to do that is because then I would HAVE to have the 'Locker' part of my library whenever I want to use the file system stuff; it would be more tightly coupled.
I'm sure you'll have comments about the design and some will say "SplFileObject does all/most of this". I've included methods in here for examples and not all the methods I implemented are here so this isn't the only functionality I've written. All these comments and more are welcome, however, because they might land me on a design that will avoid this whole issue.
Thank you

Answer 1

In case the type of the locked classes doesn't matter, you could go with a Decorator pattern, e.g.
class Lockable
{
protected $lockable;
public function __construct($lockable)
{
$this->lockable = $lockable;
}
public function lock()
{
// .. your code to lock $this->lockable
}
public function __call($method, $args)
{
return call_user_func_array(array($this->lockable, $method), $args);
}
}
This way you are not duplicating logic. The drawback is that you cannot use the decorated instance in methods requiring the decorated type (unless you add appropriate interfaces and delegate all calls).
The Strategy pattern would be another option:
class LockingStrategy
{
public function lock($fileSystemObject)
{
// your code to lock $fileSystemObject
}
}
class ZipFile
…
public function __construct(LockingStrategy $strategy)
{
$this->lockingStrategy = $strategy;
}
public function lock()
{
$this->lockingStrategy->lock($this);
}
}

Answer 2

I think you should look into the Strategy pattern. Consider using composition of a Lockability strategy rather than trying to inherit it.