Team. We have been thinking and doing less hunting and pecking recently. One thought which has made itself apparent is the use of interfaces for realizing the "dynamic nature" of reflection when invoking page concern handlers in CABOOSE and the action-able data structures which we mentioned in the last few web-post. As with many design decisions in computing, trade-off exist. Using an interface requires that not only is the method signature of the behavior under a contract, but also its identifier likewise is fixed. This might be a non-issue in some implementations, but in some development environments identifier names must follow an "organization-dependent" standard. So, simply calling the method "render" or "draw" might not be acceptable in all cases. Also, a developer might decide that the identifier for the method which fills-in the page content should reflect the purpose of the content which it is drawing in the form of page markup. This would increase the readability and maintainability of the source.
Interfaces for Actionable Data-Structures
The use of interfaces in the creation of action-able data structure nodes might be worthwhile since an informal form of name standardization exists among the behaviors found in these structures. So, an ActionableNode interface with an "action" method which bundles the methods which it should invoke in the before or after events of a push, pop, peek,enqueue, dequeue, and etc. would be acceptable. This is only true if the design permits a constant set of behaviors for a node with each data structure action. If this set of behaviors is variable, then using reflection might be the best choice.
A few simple notes for this day. Since we lost our text files of the second chapter summary, we will deliver the summary of the Ozark 1.0 early draft specification which we promised weeks ago when we find time for recompiling it.
Enjoy This Week....
The CABOOSE Team
No comments:
Post a Comment