Two Laptop Bag
The moose likes Java in General and the fly likes Design question - getter/setter or Model Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Design question - getter/setter or Model" Watch "Design question - getter/setter or Model" New topic

Design question - getter/setter or Model

Vic Newman
Ranch Hand

Joined: Mar 01, 2002
Posts: 33
Just wanted some feedback on a design discussion we are having on a project. We will be writing the backend database access routines. My question is this. Should we use the getter setter method where we populate and retrieve the data with get and set methods within the same class as the sql query OR should we use the model approach. By this I mean creating a model class that has the getter and setters in it and creating an instance of this class in the data access routine and passing it back to the calling class. By using the getter and setters in the same class as the data access you do not
have to worry about creating an instance of the model to pass the data back to the calling method. you could simply call the
appropriate getXXX methods as follows:
PersonData pd = new PersonData();
name = pd.getName();
address = pd.getAddress();

Using the model method you would do as follows:
PersonDataModelModel pdm = new PersonDataModel();
PersonData pd = new PersonData();
pdm = pd.retrieveData();
name = pdm.getName();
address = pdm.getAddress();

Feedback and/or constructive criticism welcome.
Thanks Vic
David Weitzman
Ranch Hand

Joined: Jul 27, 2001
Posts: 1365
The model approach seems like more abstraction than necessary. Someone or other once said, "Program to an interface, not an implementation" (it is either straight out of or quoted in Design Patterns I think). The first interface seems simpler to use without causing any huge implementation problems (can your transaction control needs be met by both?).
Another approach would be to use one of the freely-available object-relational mapping tools out there. There are quite a few strong open-source implementations available for Java.
David Weitzman
Rob Levo
Ranch Hand

Joined: Oct 01, 2000
Posts: 167
Definately check out DB-Java Object middleware. Might do exactly what you are looking to accomplish and for free.
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1873
i agree with David for sure.
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
If you use a major database like Oracle, check out the SQLData interface. A very clean implementation.

Reid - SCJP2 (April 2002)
Ilja Preuss

Joined: Jul 11, 2001
Posts: 14112
A posting from usenet I found to be related to this thread:

----- Original Message -----
From: "Robert C. Martin" <u.n.c.l.e.b.o.b.@.o.b.j.e.c.t.m.e.n.t.o.r.d.o.t.c.o.m>
Newsgroups: comp.object
Sent: Thursday, May 09, 2002 6:21 PM
Subject: Re: Persistence design

> On 6 May 2002 08:03:55 -0700, (SerGioGio)
> wrote:
> >Hello,
> >
> >I have a "little" question about persistency.
> >
> >Let's say I have an "abstract" class A, and concrete classes dA_1,
> >dA_2, ..., dA_n that are derived from A.
> >I have to "store" instances of dA_1, dA_2, ..., dA_n in a database
> >(i.e store a representation of their state). The way the instances are
> >store depends of course of their class.
> >
> >1) The first solution that came to my mind is to have a method "store"
> >in class A :
> >
> >A
> >operation: store(Database)
> >
> >The method "store" is then refined in each derived classes.
> This can work well, but it violates the Single Responsibility
> Principles (SRP). A class should have only one reason to change. A
> class that takes care of business rules, and also knows about the
> persistence mechanism has at least two reasons to change. Coupling
> persistence and business rules is not a good idea. When one changes,
> the other is at risk.
> >
> >2) The second solution is to have a class "Storer" that work like a
> >visitor pattern :
> >
> >Storer
> >operation: store(A)
> >private operation: store(dA_1)
> >private operation: store(dA_2)
> > .
> >private operation: store(dA_n)
> >
> >here, the method store(A) performs a dispatch of some kind to call the
> >appropriate method store(dA_*).
> >
> >I guess the first way is more "Object Oriented", the second way is
> >"Functional".
> Actually, it's the other way around. The first is coupled, and the
> second is decoupled. Since OO is a technique for decoupling, the
> second technique is more OO than the first.
> >To me, the second way is more intuitive, and it
> >establishes a strong separation between the objects and the way they
> >are stored.
> Exactly.
> There are some other options.
> 3) Consider using the Proxy pattern. This pattern completely
> decouples persistence from business, to the extend that none of the
> business rules know anything at all about persistence. You can read
> about this technique in the Design Patterns book. There's also a
> detailed chapter about it in my upcoming book Principles, Patterns,
> and Practices of Agile Software Development, Robert Martin, Prentice
> Hall, 2002. This book will be available in September.
> I've posted this chapter in the resources section of
> It's in the list of recent articles. It's also
> in the News section of the home page.
> Robert C. Martin | "Uncle Bob"
> Object Mentor Inc.| unclebob @ objectmentor . com
> PO Box 5757 | Tel: (800) 338-6716
> 565 Lakeview Pkwy | Fax: (847) 573-1658 |
> Suite 135 | |
> Vernon Hills, IL, | Training and Mentoring |
> 60061 | OO, XP, Java, C++, Python |
> You and I can enjoy the experience of not always seeing
> eye-to-eye, but we can also respect each other, even when
> you might find some idea of mine totally ludicrous.
> -- Richard Riehle

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
I agree. Here's the link:
subject: Design question - getter/setter or Model
It's not a secret anymore!