• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: Instantiating the data access class

 
Mogens Nidding
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys (and gals).
This is the design I am planning to implement: There are a couple of
statements I am unsure of (not telling you which ones ), so any comments are welcome.
  • I need many at least one Data instance per client because the lock(int recNo) method in Data must be able to identify the calling client to guarantee that that one client and no other clients can access the locked record.
  • A particular Data instance is a great identification of a client.

  • You could even say that a Data instance IS a client. I can't see a better way to identify the client.
  • Using the current thread as client identification won't work because RMI makes no guarantees as to what thread will invoke the exported methods.
  • All data instances (for a given canonical database path name) must access the same shared file and the same shared list of locks.
  • I COULD make the shared file and shared list of locks static because I KNOW there is only one file, but it would be more elegant not to restrict the program to one file. (Or perhaps it would just be more work than is called for?)
  • This means I must maintain a mapping from canonical path name to a shared file. Having the mapping be a static variable of Data is fine.

  •  
    Mogens Nidding
    Ranch Hand
    Posts: 77
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    My assumptions above had some interesting consequences. They led me to create an inner class, Table, to encapsulate all those objects that were shared by all the Data instances:

    I personally think the dotted table.header.magicCookie notation makes the data organization very clear. However, I am beginning to doubt my coding style, since it does smell a bit like C structs.
    My inner Object Oriented Design leprechaun is shouting to me that I should obviously move all the table accessing methods into Table class. Trouble is that "the table accessing methods" just so happens to be the bulk of the Data class. In effect, the Data class will just become a thin adapter that doesn't really do anything except identify clients to the Table lock/unlock methods class, as in

    Is it OK to just have the Data class be a thin adapter? Anyone has any advice? Am I even asking a real question?
    Bewildered regards,
    Nicky
    [ March 12, 2004: Message edited by: Nicky Bodentien ]
     
    Javini Javono
    Ranch Hand
    Posts: 286
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi,

    Is it OK to just have the Data class be a thin adapter?

    Concerning your coding example, where the Data class delegates
    it's work to a LockManager class, that's fine, I would suspect.
    In general, my code operates the same way.
    Aside: Note this interesting remark from George in a relatively recent
    post: where he said that both in local and remote mode, he used
    his LockManager, and he received a 100% score.
    Concerning the organizing of the files to get the "One-ness pattern"
    (a name I'm making up). That is, you have one database file,
    and associated with it, are single instances. And, if you had another,
    second database file, associated with it would another set of
    single instances.
    Right now, as I work with JUnit for unit testing, and continue to augment
    the higher system testing of my database using George's super software
    exerciser as the thread generator, I've taken the shortest path, to get things
    moving: i.e., used singletons, used static, et cetera.
    Now, once I'm comfortable that my design is flawless, then I've decided that
    the best route to take to create this "one-ness pattern" is to use the
    factory pattern, although, when you create a set of components, the factory
    pattern may have a different name, such as, and I make this up: meta
    factory pattern (such as a pattern which creates one look and feel which
    consists of different components).
    I am not a Java style expert, but, it would be my opinion that you don't need
    this kind of construct: ClassA.ClassB.ClassC.element, instead, at least this
    is how I do it, if ClassA contains a ClassB instance, ClassA simply has a reference
    to ClassB. It is not unusual, at least for how some of classes are set up for
    other functions, to have ClassA contain a reference to ClassB which in turn contains
    a reference to ClassC which in turn contains a reference to ClassD.
    But, this may be a manner of style. For instance, if only ClassA refers to its own
    instance of ClassB, maybe ClassA.ClassB is more appropriate. So, at least you
    have me thinking about this; but, since you declare the inner class as default
    access, private, or what have you, you can still do the same thing with standard
    references.
    In general terms, I prefer stand-alone classes. I like a relatively small source
    .java file. I find it easier to work with. Granted, however, you will find instances
    in text books, for instance, if you were writing an Iterator for your own collection
    class, where having inner classes makes sense.
    Forgive me for perhaps rambling, I'm sure others will have more precise comments
    on your question, and I look forward to reading their responses.
    Thanks,
    Javini Javono
     
    Javini Javono
    Ranch Hand
    Posts: 286
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi,

    Is it OK to just have the Data class be a thin adapter?

    Concerning your coding example, where the Data class delegates
    it's work to a LockManager class, that's fine, I would suspect.
    In general, my code operates the same way.
    When I answered this question last time, I was basing my response
    on my memory. Although there may be no tangible difference, and keep in
    mind that certainly things will change if and when I decide to
    refactor, here are my classes:

    I'm not suggesting that you should consider the above good style or even
    emulate it; but it simply shows that I treat Data very thinly indeed (at least
    for now, unless I change things around in the future and refactor). The
    net effect, as you can see, however, is almost identical (I don't yet pass
    in "this", this might change, but if, when, or how, is not yet known yet)).
    Thanks,
    Javini Javono
    [ March 14, 2004: Message edited by: Javini Javono ]
     
    Mogens Nidding
    Ranch Hand
    Posts: 77
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks for your replies. Funny that we have almost the same design :-)
    I still haven't figured out a totally clear design. My latest approach is a hybrid where the Data class handles all the locking and a TableFile class handles all the I/O:

    I good things about the new design are that
  • the locking related code

  • now has the client id it needs at hand in form of the this
    reference, and
  • the seperate locking and I/O reponsibilities are now

  • also handled by seperate classes!

    The downsides are that
  • not only is my inner Table class back - now I also

  • need to synchronize explicitly on the table object.
  • with every new helper class, I feel an obligation to

  • generalize its API and documentation beyond just helping
    with the one thing it was intended to do: For instance,
    can I excuse that TableFile.update throws the odd
    RecordNotFoundIOException instead of a proper IOException?
    Because if I can't, then the helper class soon becomes
    more burdensome than helpful.

    In the end though, I think I'll stick with the later
    design.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic