Take the 2-minute tour ×

I'll try and summarize.

  • Using Hibernate framework for ORM (not really relevant)

Here's my idea:

  • I want all my model classes (which purely contain get/set for fields, represent my tables within) to all inherit from a blank parent class

  • A single database class for record retrieval/storage containing many methods for these, the method that. For the methods that return a collection, they return a type of parent object, and are cast to the correct class type upon retrieval

Small Example

Parent Class (parent object)

public class DataModel {


Child classes

public class A extends DataModel {

    private String name;
    private String message;

    public A (String name) {
        this.name = name;

    public String getMessage() {
        return message;

    public String getName() {
        return name;

    public void setMessage(String message) {
        this.message = message;

    public void setName(String name) {
        this.name = name;


Database Class

public class Database {

    public DataModel returnSingleRecord() {

//eventually have an enum as a param to determine what type of child object of DataModel they would like returned

        //data retrieval here etc
        A a = new A("ashley");
        return a;



Example usage

public class MainController {

    public static void main(String[] args) {

        Database r = new Database();

        A a = (A) r.returnSingleRecord();



I'm going to have a total of 12 classes similar to A. Eventually my plan is to build a Enum class and each method that returns a collection will accept an Enum value, a switch statement within the method will determine the what object is returned such as A, B or C.

Is this a good idea? it honestly seems like a good method of significantly reducing redundant code and eliminating all database methods to less than 10 for this project. Just a yes that seems like would suffice as an answer, seems too good to be true :).

EDIT: just to note if I was to pass data into a storage method, I would have to use DataModel as a type and instanceof to determine the class type, this can be done in a method so still seems like a good idea.

EDIT2: Come to the conclusion that it's a good idea, however for returning specific information e.g. between dates, a few classes which extend Database would be the most suitable option.

share|improve this question
add comment

closed as not constructive by casperOne Mar 19 '12 at 18:00


1 Answer

up vote 1 down vote accepted

Yes, I think this is a good idea. We're doing a big project using a database for one of my classes right now and we have a top parent class in our model called "BusinessObject" which has an id (a GUID), a boolean for alreadyInDatabase (to know whether the save needs to be an insert or an update) and a boolean for dirty (anytime you call a set method, it sets that boolean to true to know whether the object differs from what is in the database. It's proved to be super helpful. We've also programmed a really helpful and generic Data Access Object for getting things in and out of the database. I know that frameworks handle most of this stuff though. Anyway, your plan sounds good to me :)

share|improve this answer
add comment
