Chemistry Reference and  Research
           
 
Periodic Table
- standard table
- large table
 
Chemical Elements
- by name
- by symbol
- by atomic number
 
Chemical Properties
 
Chemical Reactions
 
Organic Chemistry
 
Branches of Chemistry
Analytical chemistry
Biochemistry
Computational Chemistry
Electrochemistry
Environmental chemistry
Geochemistry
Inorganic chemistry
Materials science
Medicinal chemistry
Nuclear chemistry
Organic chemistry
Pharmacology
Physical chemistry
Polymer chemistry
Supramolecular Chemistry
Thermochemistry

Double chance function

A double chance function is a software design pattern with a strong application in cross-platform and scalable development. It is easiest to explain it with an example.

Consider a graphics API with functions to DrawPoint, DrawLine and DrawSquare. It is easy to see that DrawLine can be implemented solely in terms of DrawPoint, and DrawSquare can in turn be implemented through four calls to DrawLine. If you were porting this API to a new architecture you would have a choice: implement three different functions natively (taking more time, but ultimately providing a more optimal solution), or write DrawPoint natively, and implement the others as described above using common, cross-platform, code.

The double-chance function is an optimal method of creating such an implementation, whereby the first draft of the port can use the “fast to market, slow to run” version with a common DrawPoint function, while later versions can be modified as “slow to market, fast to run.” Where the double-chance pattern scores high is that the base API includes the self-supporting implementation given here as part of the null driver, and all other implementations are extensions of this. Consequently the first “port” is, in fact, the first usable implementation.

For those that read C++ easier than English, one typical implementation would be:

class CBaseGfxAPI {
virtual void DrawPoint(int x, int y) { /* Abstract concept for the null driver */ }
virtual void DrawLine(int x1, int y1, int x2, int y2) { /* DrawPoint() repeated */}
virtual void DrawSquare(int x1, int y1, int x2, int y2) { /* DrawLine() repeated */}
};

class COriginalGfxAPI : public CBaseGfxAPI {
virtual void DrawPoint(int x, int y) { /* The only necessary native calls */ }
virtual void DrawLine(int x1, int y1, int x2, int y2) { /* If this function exists
 a native DrawLine routine will be used. Otherwise the base implementation is run. */}
};

class CNewGfxAPI : public CBaseGfxAPI {
virtual void DrawPoint(int x, int y) { /* The only necessary native calls */ }
};

Note that the CBaseGfxAPI::DrawPoint function is never used, per se, as any graphics call goes through one of its derived classes. So a call to CNewGfxAPI::DrawSquare would have its “first chance” to render a square by the CNewGfxAPI class. If no native implementation exists, then the base class is called, at which point the virtualisation takes over and means that CNewGfxAPI::DrawLine is called. This gives the CNewGfxAPI class a “second chance” to use native code, if any is available.

With this method it is, theoretically, possible to build an entire 3D engine (applying software rasterizing) using only one native function in the form of DrawPoint, with other functions being implemented as and when time permits. In practise this would be hopelessly slow, but it does demonstrate the possibilities for double-chance functions.


References

01-04-2007 01:16:19
The contents of this article are licensed from Wikipedia.org under the GNU Free Documentation License. How to see transparent copy