Information Technology Reference
In-Depth Information
But you might still be wasting some bandwidth. Your last design works
best when every known customer calls every day. That's probably not true.
If it is, your company has customer service problems that are far outside
the scope of a software program.
How can we further limit the size of each transaction without increasing
the number of transactions or the latency of the service rep's responsive-
ness to a customer? You can make some assumptions about which cus-
tomers in the database are going to place calls. You track some statistics
and find that if customers go six months without ordering, they are very
unlikely to order again. So you stop retrieving those customers and their
orders at the beginning of the day. That shrinks the size of the initial trans-
action. You also find that any customer who calls shortly after placing an
order is usually inquiring about the last order. So you modify the list of
orders sent down to the client to include only the last order rather than all
orders. This would not change the signatures of the server methods, but it
would shrink the size of the packets sent back to the client.
This hypothetical discussion focused on getting you to think about the
communication between remote machines: You want to minimize both
the frequency and the size of the transactions sent between machines.
Those two goals are at odds, and you need to make tradeoffs between
them. You should end up close to the center of the two extremes, but err
toward the side of fewer, larger transactions.
Item 29: Support Generic Covariance and Contravariance
Ty p e v a r i a n ce , a n d s p e c i fi c a l l y, cov a r i a n ce a n d co n t r av a r i a n ce d e fi n e t h e
conditions under which one type can be substituted for another type.
Whenever possible, you should decorate generic interfaces and delegate
definitions to support generic covariance and contravariance. Doing so
will enable your APIs to be used in more different ways, and safely. If you
cannot substitute one type for another, it is called invariant.
Ty p e v a r i a n ce i s o n e o f t h o s e to p i c s t h a t m a ny d e ve l o p e r s h ave e n co u n -
tered but not really understood. Covariance and contravariance are two
different forms of type substitution. A return type is covariant if you can
substitute a more derived type than the type declared. A parameter type is
contravariant if you can substitute a more base parameter type than the
type declared. Object-oriented languages generally support covariance of
parameter types. You can pass an object of a derived type to any method
 
 
Search WWH ::




Custom Search