Java – Split one big class on sub-classes

java

I have a generic question and I don't understand how create what I want.
I writing a basic program they can access to one database an do some SQL request, etc. But at the moment I have one big class with all SQL for all the tables from the database. And I want slipt this class in different classes for make the code more easy to read and implement stuff. I think the best solution is create one subclass for each table on the database and on for this class put all the methods related on this class. But later I don't understand how I can call this methods from the class. Because for access to the database I create an object DataBase on the main application and if I want call a method just I do a database.methodIWant().

At the moment I have:

DataBase (this class have all the methods for the databases) extends DataBaseUtil
DataBaseUtil (this class contain all methods and information for connect to the database)

and I crate the database object with DataBase db = new DataBase();

And I want something like:

DataBase (this class have all the methods for the databases) extends DataBaseUtil
DataBaseUtil (this class contain all methods and information for connect to the database)

and classes for example:

DogSQL (all the methods for the table dog on the database)
CatSQL (all the methods for the table cat on the database)

and I create the database object with DataBase db = new DataBase(); and call methods like db.methodFromDogSQL();

I don't understand how do this. I don't understand if a need use abstract, interface, inheritance for this or which is the best implementation for this. I'm starting and my knowledge in java is a bit basic, so I want learn how do this type of stuff.

Best Answer

There is no need for using subclasses here, Dog and Cat should not be derived from Database (in fact, this would result in a typical example of how to not to use inheritance).

Instead, you could have the Create/Read/Update/Delete methods of the classes Dog or Cat just have a parameter of type DataBase (or IDataBase, an interface, if you want to be able to mock the database object for testing). For example, there should not be a method in DataBase like db.SelectDog(int Id), only a (maybe static) method in the class Dog like Dog.Select(IDatabase db, int Id). That method could return a Dog object, which corresponds to a row in your Dog table.

The "Dog.Select" method may contain the SQL code needed and call some general methods of IDataBase for selecting data, but in no way should your database class have knowledge about the SQLs needed for specific business objects.

Related Solutions

Java – Using Super Keyword to Access Super Class Members

In addition to all the above, consider the following scenario:

You start out with these two classes.

 class A {
    int i = 20;

    A() {
        System.out.println("I am in constructor of the parent class");
    }
}

class B extends A {
    int i = 30;

    B() {
        System.out.println("I am in constructor of the subclass");
    }
}

You compile both classes, it creates two class files: A.class and B.class

Now you change your mind and rewrite A:

 class A {
    int i = 10;

    A() {
        System.out.println("I am in constructor of the parent class");
    }
}

You recompile A, so you get a new A.class, which you replace the old A.class with

Now the question is: how would B know that As initialisation code has changed? You haven't recompiled B, nor should you be required to do so. After all, B may already be packaged up in a different jar, maybe even in a different product you have no control over.*

The only reasonable way to support this case is for Bs constructor to start with calling As constructor and let A initialise itself.

*This may sound far-fetched at first, but this is exactly what happens when internal implementation details of JDK classes are changed. All the previously compiled Java applications in the world should run seamlessly with the new JDK.

Java Database Class – What to Include

The question is very confusing. What makes it more confusing is the fact that you decided to use Job and Jobhandler as examples which makes one think the question is about database jobs (scheduled tasks). But after reading the edit I guess you are trying to write a DAO and were talking about jobs as in "a position of employment".

Don't write a Database class. Just create a JDBC connection and pass it to the DAO.

You could either try to write a generic DAO or or write individual DAOs for each entity. DAOs will have SQL sentences inside it.

Another pattern is Active Record Pattern.

DAOs access databases, encapsulating SQL and allow you to populate the business objects. DAOs can also have methods that return lists of data.

Active Record is usually used to implementg business objects that manage write and read their data from the database themselves. This is considered too much since classes shouldn't maanage their own persistence. Active Records represent a single row of a table.

This question about refactoring an Active Record into DAO form will help you because it has a complete example of an object that accesses the databases and inserts or updates and its answers explain how to implement DAO instead.

Best Answer

Related Solutions

Java – Using Super Keyword to Access Super Class Members

Java Database Class – What to Include

Related Topic