With the below piece of thread related code, I see that author of Thread class is hiding the details about the working of start() method. What a user of Thread class need to know is, class Thread would expect a piece of his own code which will be an instance of Runnable‘s anonymous concrete sub-class that gets passed.
/* TestThread.java */
public class TestThread{
public static void main(String[] args){
Thread threadObject = new Thread(new Runnable(){
public void run(){
/* your own code that has to run*/
System.out.println("a new thread");
}
});
threadObject.start();
System.out.println("Main thread");
}
}
But in this below program, It looks like we partially hide the implementation details of listFiles(filter) method. Because if author has to change the logic of listFiles(filter) in future without affecting the users, he should make sure that method signature boolean accept(File dir, String name); should not get affected.
/* ListDirectoryWithFilter.java */
import java.io.File;
import java.io.FilenameFilter;
public class ListDirectoryWithFilter{
public static void main(String[] args){
String path = System.getProperty("user.home") + File.separator + "workspace" +
File.separator + "JavaCode" + File.separator + "src";
File dir = new File(path);
if(dir.isDirectory()){
File[] files = dir.listFiles(new FilenameFilter(){
public boolean accept(File dir, String file){
return file.endsWith(".java");
}
});
for(File file : files){
System.out.println(file.getName());
}
}
}
}
Do you think, it would have been better that listFiles(filter) method just expect a regular expression(*.java) from the user and rest is the result that user expects?
It looked a bit unnecessary approach for me, to implement a two argument accept(,) method and then pass it to listFiles() method.
So, Are such implementations a good practice? If yes, when do we think of such implementations?
Yes, it is good practice. It looks a bit boilerplate and weird, because Java 7 and below does not support functional programming very well.
The difference to just a regular expression is, that a regular expression limits you in your options to filter for files. E.g. lets say you want to filter files not by their name only but [just/additionally] by their content or other metadata (in the future). Then, regular expressions are insufficient to do this. Also, they can be quite slow – and a malicious regex might even break the program if you don’t use techniques to prevent it from taking a lot of time to execute the regex.
To explain it more general: what is what you want to do? You want to filter files of a directory. That’s it. Not more, not less. I can’t read anything of regular expressions in this explaination, so they should not be used. A general filter approach should be used which includes to be able to use regex but does not limit it to regex.
5
This API is less about hiding implementation details and more about deferring to the programmer for the interesting parts of the action.
listFiles() knows how to iterate over the files in a directory and return a subset of the them. Thread knows how to run code in parallel to the code that is currently running. However, from the application’s perspective, those are the boring parts. The interesting parts are the decision of if a file should be include and the actual code that is run in parallel. By taking a functional interface (a concept formalized in Java 8), these implementations do exactly what they need to and no more. The programmer calling these methods know exactly how to implement the interesting parts. This style of API gives the programmer the flexibility to do what they want, even if it might be more complex than the most common cases.