• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Design question - getter/setter or Model

 
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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();
pd.retrieveData();
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
 
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 167
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Definately check out DB-Java Object middleware. Might do exactly what you are looking to accomplish and for free.
 
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i agree with David for sure.
regards
maulin.
 
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you use a major database like Oracle, check out the SQLData interface. A very clean implementation.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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, serge.malonga@supelec.fr (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
> www.objectmentor.com. 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 | www.objectmentor.com
> Suite 135 | | www.XProgramming.com
> Vernon Hills, IL, | Training and Mentoring | www.junit.org
> 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
reply
    Bookmark Topic Watch Topic
  • New Topic