|
The Transition to Concurrency
 2. Default Constructers
A default constructor means that the class is initialized with no information at all. This is rarely useful, and it usually means that you have an initialize function or a number of set-functions etc. for later initialization. An object that has been instantiated but not initialized is a zombie object and a liability to have lying around. Supply all required information to the constructor.
If your class is complex, the constructor parameter list might grow long. This is in itself a smell that your class is probably too complex, but there are situations where that's just the way things are. If you are in that kind of situation, you might be able to benefit from the Essence design pattern.
3. Public Validity Status Functions
If your class has a public bool IsValid() function or something similar, you are effectively leaving contract enforcement up to the user. This is bad for several reasons. A class with no mutable state needn't such checks except during construction. If the check fails there, an exception should be thrown so that the class is never instantiated. If you don't use exceptions, make an assertion and check the contents before constructing your object. This way, your class never violates the invariant.
If, however, your class has mutable state, adding such checks can be a good idea, only they should remain private. Read up on contract programming for in-depth discussion.
4. NULL-Pointer Checks
Don't code defensively. Many null pointer checks are just a form of contract validation which means that entry #3 applies here as well. If you feel that a null-pointer might have slipped in somehow, make an assertion. Not an if-statement. (Note that people often use null pointers as a valid "none" value which is perfectly fine).
5. Inheritance
There is no problem with inheritance itself. There may be uses for it in your design, but in general, it doesn't fit very well into a functional system. If a class is immutable, subclassing it would either violate this or simply supply more read-only methods.
6. Large Classes
Besides the obvious fact that a large class is probably also a complex class, large classes are an even greater problem if they are to be used in a concurrent environment. If your class is immutable, there is more information to copy around (but if your class is large, it is probably not immutable. The two things seem almost mutually exclusive). If not, there is a greater chance that the invariant can be broken and there is more data to keep consistent during transactions or semaphore locks.
StateAid
Even without semaphores, concurrent code is hard to debug and verify, mostly because you cannot determine the order of events by inspecting the code.
For this purpose, we have developed a small tool called StateAid that enables you to visualize execution in a non-linear fashion.
Conclusion
Concurrency is going to be part of most developers' lives in the future. C++ and languages like it are poorly suited for concurrency as it is today.
Developers have so far been spoiled by the fact that compilers have done a pretty good job of optimizing code for the evolving cpu architectures. However, traditional imperative code is hard to parallelize automatically so we cannot expect the same to happen with the new shift in hardware trends.
Semaphores are common and well-known, but using them correctly is difficult. If you want to prepare for concurrency, you could start the transition by becoming familiar with immutability, persistent data structures and active objects.
|
|
|
|
|
Previous