Dr. Dobb's Journal - November 2007 - (Page 56)

d11jiri_p8db 9/11/07 12:58 PM Page 56 State of the Art REUSABLE ASSOCIATIONS template class Aggregate { Participants(ParentAggregate, ChildAggregate); void add(Parent *p, Child *c){ p->id.children.add(c); c->id.parent=p; } p->children.add(c); c->parent=p; // which is interpreted as // p->ID.children.add(c); // c->ID.parent=p; } Style 3: No additional keywords. The compiler is just smarter. In templates that implement the associations, it detects references to participating classes and transparently inserts ID: template class Aggregate { Participants(ParentAggregate, ChildAggregate); void add(Parent *p, Child *c){ The implementation should let the debugger step through all the code when debugging association-based applications as well as when debugging associations themselves. Interim Implementation Until the time languages and compilers support reusable associations, we implemented a library of associations, which uses a code generator (precompiler). The implementation and the application interface are the same in both C++ and Java. (For free source-including documentation, see www.codefarms.com/ incode.htm.) The precompiler is coded with the library and uses itself to recompile. Because the code generator must substitute member names in the association files, we decided not to use templates and do all the substitutions with the precompiler. The result is a simple scheme that makes coding of new associations easy and readable (Listing Five; available online). This approach is a cross between style 1 and style 2. The library inserts each group of members as one instance of an automatically generated class (ZZ_Net, ZZ_Pin, ). When interpreting the implementation of: Association Aggregate pins; the code generator performs the following substitutions: $$ $0 $1 $2 is replaced by pins ZZds._pins Net Pin Instead of using keyword Participants, the library registry file (Listing Five) describes the roles of participating classes and the UML representation of individual associations. For example, B1-* means “bidirectional one-to-many.” Conclusion We have no doubt that eventually, libraries of associations will supersede existing class libraries. The new libraries will provide a uniform treatment for existing containers, intrusive data structures, associations, structural design patterns, and other data organizations missing in the standard libraries today. Associations will become first-class entities—equally visible and important as classes. Experience with several libraries based on this idea—one of them used commercially for over 18 years—shows that this approach is viable and significantly increases readability, reusability, and supportability of the resulting software. DDJ 56 Dr. Dobb’s Journal l www.ddj.com l November 2007 http://www.codefarms.com/incode.htm http://www.codefarms.com/incode.htm http://www.programmingresearch.com http://www.programmingresearch.com http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - November 2007

Contents Hmmmm Alia Vox Developer Diaries Developer’s Notebook Smart Compilers - But Smart Enough? Conversations Grid-Enabling Resource-Intensive Applications Distributed Computing: Windows and Linux Adobe AIR: Desktop/Web Convergence Transparency on Demand Reusable Associations Effective Concurrency The Agile Edge Swaine’s Flames

Dr. Dobb's Journal - November 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.