Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

URLyBird : Locking in Data?

 
R van Vliet
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey guys,

A matter of taste perhaps, but I've pretty much exclusively seen the approach of having Data inherited DBAccess, and then inside the Data class people use a seperate "file database" class and another seperate lock manager of some sort.

Wouldnt it be slightly better if Data actually implemented the lock and unlock methods, and then have..say...FileData extends Data and implement the database I/O in FileData?
 
Musab Al-Rawi
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is possible but then you will be violating some of OO princples such as delegation (delegating job to a responsible class). As you know DBAccess is working as an interface to a facade, this facade should delegate jobs to responsible classes.

-musab
 
R van Vliet
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi there,

Perhaps I'm being overly difficult but where does it say DBAccess must be a facade interface? Isn't it more OO friendly to create a facade for room management in general and expose that to the client? Or are you proposing you actually have two facades?

The reason I'm having some doubts about considering DBAccess a facade interface is because facades are suppose to expose a simplified interface to a collection of more complex functionality. In the case of DBAccess this isnt really the case since every DBAccess method almost directly translates to methods of either the file IO class or the lock management class. But your point about lacking delegation is certainly a valid one.

Please share your opinions, I'm curious to know what the pros and cons are of these options.
 
Anita S�rensen
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a Data class that directly implements all methods in the DBAccess, exept the locking mechanisms. To keep OO principles, and create clean code, I seperated locking mecanisms into a locking manager. The locking uses a hashmap to keep track of the locked records, and the entire Data class don't need this information.
 
R van Vliet
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
yes I have exactly the same solution now. Lock management is something i concluded should be delegated to a seperate class but I still feel Data should do the actual file database work. I think many people opt for delegating this as well simply because the Data class is so badly named. The term Data is so generic that it does suggest being a facade or interface.

I'd still be interested in opinions from people that did delegate file IO to a seperate class since the vast majority of people go for this solution and I have the feeling I may be missing a vital point.
 
R van Vliet
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm actually running into an issue with delegating locking to a seperate class as well. My DBAccess method signature looks like this :



Which means either the LockManager has to be able to determine whether or not the specified record exists and thus have a reference to the DBAccess implementation, or the Data.lockRecord implementation would roughly look like :



The first approach sort of breaks the use of delegation, and the latter seems a bit messy. Opinions?
[ November 16, 2007: Message edited by: R van Vliet ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic