Lock Adapter

A MicroArchitecture element. It encapsulates locking state.

This acts as a synchronization point for other elements. In its simplest form it simply redeclares the adapted interface with synchronized attributes. In C/C++ some extra work needs to be done declaring and manipulating monitors.

A more functional synchronization interface can process complex sharing semantics such as different isolation levels e.g. shared-read, exclusive-write. It also separates the locking from the objects being locked allowing for locking of any group of objects e.g. a range of elements in an array.

It can provide querying of lock state by making this state explicit.

It can provide event-generation services on lock status changes.

Examples: synchronizedCollection in Java is a simple lock adapter.

I think LockProxy? or LockDecorator? is a more suitable name for this pattern than LockAdapter. Because synchronizedCollection does not change interface at all. It just adds some responsibility to the given object. What do you think? -- HiroshiYuki.

That depends on your viewpoint. If you use the GoF software definitions then you might be right. As an architectural issue, all of the connective structures in GoF (Bridge/Proxy/Adapter/Facade/Decorator...) are adapters (or sometimes 'connector' in the literature). Within this structural context, any object which inserts itself between two interacting objects is an adapter.

Since I consider synchronization an architectural attribute, I prefer to use architectural terms. The architectural term is more stable under modification. Thus a LockAdapter may gain extra interfaces to expose its own behaviour/state e.g. querying the lock state of the object. This doesn't change any inter-object structure yet would require renaming under the GoF's [over]strict definitions. -- RichardHenderson.

The GoF names largely depend on DeGeneralization, which is why discussions like this are so ubiquitous. I really wish they had've said, "Snafrangle" instead of "Adapter", "Flowzflazzle" instead of "Decorator", and so on.

Its a good point though. I often find myself wrestling with terms. Referring to the context explicitly resolves the issue somewhat, but doesn't always help. Each term represents turf to some people, and they aren't too far wrong in our absolutist age. A recent example was my use of StateObject. I saw no problem with this term. Unfortunately it clashes somewhat with StatePattern, and appears equivalent to ValueObject. So I changed everything to ValueObject only for Java to take it over and the functional community add an implicit non-modifiability attribute. So I'm back to StateObject. An object containing state, my definition is the shortest so I should win ;). -- RichardHenderson

I understand that Adapter of the LockAdapter is different from GoF's Adapter. Thank you! -- HiroshiYuki.

CategoryArchitecture