This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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();
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
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, email@example.com (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
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