What is the name of this file operation design pattern?

Question

Let's say I have a wrapper class for Path objects that I'm going to want to store some other information about: a hashCode, and fileType for example.

public class FileWrapperClass {
    private Path thePath;
    private String hashCode;
    private String fileType;
    ...
    public void setPathFromUserInput(JFrame whatever) { ... }
    public void generateHashCode() { ... }
    public boolean testHashCodeAgainst(Path testAgainstMe) { ... }
    public void determineFileType() { ... }
    ...
    public Path getPath() { return thePath; }
    public void setPath(Path thePath) { this.thePath = thePath; }
    public String getHashCode() { return hashCode; }
    public String getFileType() { return fileType; }
}

The logic for generateHashCode(), testHashCodeAgainst(Path), and determineFileType() don't have to be included in this FileWrapperClass, and probably shouldn't be if there are going to be potentially millions of these FileWrapperClass objects.

So, it occurs to me that I might pull this out to another class and make them static methods that operate on FileWrapperClass instances. This lets me pull out all but the most basic of getters and setters, like so:

public class FileWrapperClass {
    private Path thePath;
    private String hashCode;
    private String fileType;
    ...      
    public Path getPath() { return thePath; }
    public void setPath(Path thePath) { this.thePath = thePath; }
    public String getHashCode() { return hashCode; }
    public void setHashCode(String hashCode) { this.hashCode = hashCode; }
    public String getFileType() { return fileType; }     
    public String setFileType(String fileType) { this.fileType = fileType; }
}

public class FileWrapperClassOperator {
    public static void setPathFromUserInput(JFrame whatever) { ... }
    public static void generateHashCode() { ... }
    public static boolean testHashCodeAgainst(Path testAgainstMe) { ... }
    public static void determineFileType() { ... }
}

In fact, wouldn't it produce better performance to nix the whole getter/setter dynamic in favor of a direct access protected variable (despite breaking OO principles.. is it worth it for a performance gain?), like:

public class FileWrapperClass {
    public Path thePath;
    public String hashCode;
    public String fileType;
    ...      
}

public class FileWrapperClassOperator {
    public static void setPathFromUserInput(JFrame whatever) { ... }
    public static void generateHashCode() { ... }
    public static boolean testHashCodeAgainst(Path testAgainstMe) { ... }
    public static void determineFileType() { ... }
}

I feel like I'm on to something here. If it's an existing design pattern, then I'd like to know what it is so that I may learn it and code to it. If not, then the task is to optimize this concept.

To be clear, hashCode and fileType are arbitrary pieces of data. I'm trying to remove as much code as possible from the class that gets instantiated millions of times and put it in another singleton class with a bunch of static methods that operate on instances of the class that gets instantiated millions of times. Is there a name for that design pattern? Thanks

Answer 1

I think you're basing your "pattern" on some misunderstandings.

The logic for generateHashCode(), testHashCodeAgainst(Path), and determineFileType() don't have to be included in this FileWrapperClass, and probably shouldn't be if there are going to be potentially millions of these FileWrapperClass objects.

Do you think that the code is included in each of those millions of instances? If yes, then you're wrong, the code is shared and there is no advantage in creating separate static methods to handle them.

In fact, wouldn't it produce better performance to nix the whole getter/setter dynamic in favor of a direct access protected variable (despite breaking OO principles.. is it worth it for a performance gain?), like:

No, there is no performance gain involved here. This is micro-optimization that will be rendered unnecessary by JIT anyways.

So as a conclusion, sorry, but you're not "on to something" here, but I hope that you're "on the correct path" now.

Answer 2

对我来说，这听起来像是贫血领域模型与过早优化的结合。