Spot The Blocking
Learn about method synchronization, the Liskov substitution principle, caching, and anti-patterns.
We'll cover the following...
Synchronization
Can you find the blocking call in the following code?
String key = (String)request.getParameter(PARAM_ITEM_SKU);Availability avl = globalObjectCache.get(key);
You might suspect that globalObjectCache is a likely place to find some synchronization. You would be correct, but the point is that nothing in the calling code tells you that one of these calls is blocking and the other is not. In fact,
the interface that globalObjectCache implemented didn’t say anything about synchronization either.
In Java, it’s possible for a subclass to declare a method synchronized that is unsynchronised in its superclass or interface definition. In C#, a subclass can annotate a method as synchronizing on “this”. Both of these approaches are frowned on, but some engineers still use them. Object theorists will say that these examples violate the Liskov Substitution Principle. They are correct.
Liskov Substitution Principle
In object theory, the Liskov substitution In object theory, the Liskov substitution principle (see Family Values: A Behavioral Notion of Subtyping [LW93]) states that any property that is true about objects of a type T should also be true for objects of any subtype of T. In other words, a method without side effects in a base class should also be free of side effects in derived classes.
A method that throws the exception E in base classes should throw only exceptions of type E (or subtypes of E) in derived classes.
Functional behavior ...