Basically I am trying to make a library for handling files and directories.
The idea is there will be separate classes for FileFinding, FileReading, FileWriting etc.
What I am trying to search is there any design pattern to achieve something like :
There is just once class lets say
<?php namespace vendor/FileHandler;
class FileHandler {}
Now in the library I have specific classes let say
<?php namespace vendor/FileHandler;
class FileFinder
{
/**
* Find files by their types
*
* @param string $path path to find files in.
* @param mixed $type string or array of file type/types (extensions).
* @return array array of file names.
*/
public function findFilesByType($path, $type)
{
// do logic here.
return $files;
}
}
Now I want my library users to call the FileFinder::findFilesByType() by using the main class FileHandler::findFilesByType();
Please note: The FileFinder::findFilesByType() is not static method but I want it to be utilized as static method from class FileHanlder
Updated: The question I have asked above seems similar to Laravel's Facade pattern. But their implementation going above my head. Even I'm not sure if Facade pattern will do this.
The facade should keep a static instance of every class that provides functionality you yourself want to forward to the library users.
In the facade's static methods, utilize the above objects and forward the method calls to them. Only use this approach, if the objects you forward to are stateless, otherwise you have to create the appropriate objects inside the facades method, in order to not propagate state information between method calls.
In the following a little example in java, but you'll get the point
public class Facade {
private static final HashComputer computer = new HashComputer();
// since this operation changes state of accumulator,
// it has to create one on each invocation
public static List<String> accumulate(String... args) {
Accumulator acc = new Accumulator();
for (String arg : args)
acc.add(arg);
return acc.collect();
}
// this operation does not change state of the object it delegates to,
// so there is no need to create a new instance on every invocation
public static int computeHash(String s) {
return computer.hashFor(s);
}
// has stateless instances
private static class HashComputer {
public int hashFor(String s) {
return s.hashCode();
}
}
// instances have state depending on state of list
private static class Accumulator {
List<String> arguments = new ArrayList<String>();
public void add(String s) {
arguments.add(s);
}
public List<String> collect() {
return Collections.unmodifiableList(arguments);
}
}
}
Strictly speaking this exact way of implementing a facade just suits your needs. A facade does not have to be a utility class with static methods, it can also be an instance of a class.
The principles behind the facade design pattern are abstracting from the intrinsics of a group of classes (or of a whole layer) that are responsible for some common functionality, encapsulating the operations and granting easy, maybe high-level, access to them.
As @PeeHaa mentioned in his comment, this static facade approach indeed is not in the sense of OOP, because violates the law of demeter, which says:
A method method of a class Class should only call methods
ClassmethodmethodClassYou don't use a facade with static methods in that sense, since you call the methods on the class and not on instances of it.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments