Home > Enterprise >  Is splitting a class in two different class a good idea?
Is splitting a class in two different class a good idea?

Time:05-17

For a project I need to create report from Excel files.

I have a big design question that I can't solve myself and I haven't found a solution online.

Here is what I'm trying to do:

  1. Read the content of an Excel file
  2. With that content initialize a new Report class
  3. Profit!

The problem is that the first time I wrote that, I put everything inside my Report class (by everything I mean reading the file, formatting the fields, etc.) and I ended up with a big class.

I wasn't satisfied with that, so I tried to do something better and created a ReportReader class that contains all my reading file stuff and also getters to init a Report class. It is a good idea or should I stick to one class?

Also, could it be a good idea to create a createReport method inside ReportHeader instead of making public getters available?

public class ReportReader {
    private final File file;
    private final Sheet sheet;

    public ReportReader(File file) throws InvalidFormatException
        , IOException {
     
    }

    public ArrayList<String> getFields() {

    }

    private String formatField(String input) {

    }

    public String getName() {
    
    }

    public Cell[][] getContent() {

    }

    public String getType() throws IOException {

    }
}

and:

public class Report {
    private String name;
    private String type;
    private ArrayList<String> fields;
    private Cell[][] content;
    
    public Report(String name, String type, ArrayList<String> fields, 
        Cell[][] content) throws IOException {
    
    }
    
    public void saveFieldsModel() throws IOException {
       
    }
    
    public String getFieldsAsCsv() {
    
    }
}

CodePudding user response:

yeah, creating a class per responisibility is good practice. It is one of principle of SOLID. There is a great post about clarifying of single responsibility.

could it be a good idea to create a createReport method inside ReportHeader instead of making public getters available?

It looks like CreateReport is not related to ReportHeader. Class Report would be more appropriate place for CreateReport() method. In addition, if you will place the method CreateReport() in Report class, then you can call it like Create, not CreateReport:

public class Report {
    public void Create(){}
}

and then in user class it would look like this:

Report report = new Report();
report.Create(); // not "CreateReport()" :)
  • Related