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