views:

13

answers:

0

In all the code I've written, I have always made synchronization primitives wrapped in a single class. If my design ever produced an unencapsulated synch primitive, I redesigned until it was indeed encapsulated.

But is there a well-known design force or development circumstance (besides legacy code) that would require unencapsulated synch primitives?

I ask because I've seen other engineers make designs or code where little effort is made to encapsulate such primitives, and they act as if it isn't really a design goal to worry about. I figure the only way they could have such an attitude is if (1) they don't know what they are doing or (2) there really are so many (good?) reasons that prevent the use of such encapsulation, that there truly is no point in worrying about it.

Although I would think the answer to my question is obvious, the attitudes I encounter prompts me to ask if there is something I'm missing? What is it that everyone else knows, that I'm missing, that makes encapsulation of synch primitives an optional design goal in newly authored OO code?