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.

  • You seem to be assuming that you still need a master DataBase class even after the split, why not have dogdb.someMethod(); catdb.otherMethod(); instead of one db object for both? Also, are you sure all your SQL operations will affect only one table at a time? (most properly-normalized databases require join queries to do anything interesting) – Ixrec Apr 18 '15 at 19:41
  • In the main class. I have one object DB and this object call the methods. My database I have 3 tables (room (id,name), pets(id, room_id, name), friend(id, animal_id, name)). So first I select a room and now I can now how many animals we have in that room, so if I want know the owner of one animal I can do it. But I only want have DB on the main application for all the program, because in the constructor I create the database and I make the connection and I handle all the request. But I want split the class for one for each table for more readable code and more easy implement more methods – Jota_sk Apr 18 '15 at 19:52

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.


I suggest you study Inversion of Control and the dependency injection pattern. Take a look at this Martin Fowler article on dependency injection. Using an IoC container will help you break up your class into more manageable components and make your solution less brittle than it is now.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.