Yes, right. That's exactly what I was talking about. Well summarized. Thanks for the clear answer/explanation of what you've done.
Just playing devil's advocate here, understand...umkay?...cause I think thats' what'd be most helpful to both of us..okay?
Your implementation of how LockManager deals with the concept of record validity minimizes the leakage in terms of lines of code and simplicity of the interface between the Data class and the LockManager, yes. But...it's still there in an OO design sense.
So your LockManager implementation is forever bound (by a single teeny-weeny method call, granted) to the Data class/DBAccess interface.
Just off the top of my head, though, I wonder if by letting the LockManager not care about validity of the record but letting your Data class be the only one to know/care about could be made to work? After all, the Data class is very familiar with record validity and knows how to compute it...I wonder if we could help him keep that nasty secret to himself.
That way LockManager, lucky simple-minded young scoundrel he is, could dispense locking/unlocking calls all he wanted with nary a thought about records or valiidyt. Could it be made to be incumbent on the Data class to check...once the lock was obtained
...as to whether the record was still valid or not? Once "owned", in a locked sense, then Data could make up it's own mind about what to do if he got an invalid record, like throw a RecordNotFoundException or something after unlocking it....?
I dunno....it just seems to me with the static reference to Data removed, you'd free up LockManager to be used by other classes outside DBAccess and it'd be one less little arrow I'd need to draw on my legal pad here.
That's my biggest problem, no room left on the page.
...but if this makes no sense based on what you're got, ignore me. Remember, I'm still in the almost-no-design, certainly-no-code-blue-sky stage, so everything works correctly, cleanly and perfectly in my B&S system.