Java: repetition, overuse -- problem?

Question

I try to be as minimalist as possible. Repetition is a problem. I hate it. When is it really a problem?

1. what is static-overuse?
2. what is field-method overuse?
3. what is class-overuse?
4. are there more types of overuse?

Problem A: when it is too much to use of static?

    private static class Data
    {
            private static String fileContent;
            private static SizeSequence lineMap;
            private static File fileThing;
            private static char type;
            private static boolean binary;
            private static String name;
            private static String path;
    }

    private static class Print
    {
            //<1st LINE, LEFT_SIDE, 2nd LINE, RIGHT_SIDE>
            private Integer[] printPositions=new Integer[4];                

            private static String fingerPrint;
            private static String formatPrint;

    }

Problem B: when it is too much to get field data with private methods?

    public Stack<Integer> getPositions(){return positions;}
    public Integer[] getPrintPositions(){return printPositions;}


    private Stack<String> getPrintViews(){return printViews;}
    private Stack<String> getPrintViewsPerFile(){return printViewsPerFile;}
    public String getPrintView(){return printView;}

    public String getFingerPrint(){return fingerPrint;}
    public String getFormatPrint(){return formatPrint;}


    public String getFileContent(){return fileContent;}
    public SizeSequence getLineMap(){return lineMap;}
    public File getFile(){return fileThing;}
    public boolean getBinary(){return binary;}
    public char getType(){return type;}
    public String getPath(){return path;}

    public FileObject getData(){return fObj;}
    public String getSearchTerm(){return searchTerm;}

Related

• interface overuse
• overuse of static in a Game

Answer 1

are there more types of overuse?

Yes ... overuse of dogmatism.

You need to develop a balanced understanding of when it is appropriate to use these constructs (statics, fields, methods, classes, interfaces etc), and when it is not appropriate. Simply trying to avoid the use of some construct is plainly wrong-headed.

For example, but static fields have the problem that there can only be one instance of the field in the entire JVM. This means that code using statics tends to be non-reentrant, which can make it unusable in a lot of situations; e.g. when there are multiple threads or recursion is involved. However, there are situations where you need there to be only one instance in the entire JVM, and in those situations statics are perfectly acceptable.

(The above is an oversimplification of the issues of statics. I am trying to illustrate how you should be thinking about these things. Understand the pros and cons, and judge each case on its merits not on the basis of some dogma that you heard / read somewhere.)

Answer 2

"Just because you can, doesn't mean you should!"

If you're going to do or not do something in code (e.g. static fields, private accessors, interfaces) I think the simplest answer is have a good reason for taking that stance. Following "rules" blindly is a mistake, and often creates a maintainance nightmare if no-one is brave enough to change the code. It's better to say, "I'm using private accessors because it gives me X, e.g. I can enforce serialization for all data access/modification" But using private accessors in all classes may simply be overkill and a waste of time if it doesn't achieve anything tangible.