Conclusion
From Andrey
| Revision as of 07:06, 3 February 2006 Andrey (Talk | contribs) ← Previous diff |
Current revision Andrey (Talk | contribs) |
||
| Line 1: | Line 1: | ||
| - | The main point of this article is to consider the nature of an object's behavior as consisting of two aspects: the general behavior, provided by its class, and the behavior specific to a particular context in which the object is used. Conceptually, overriding in owner class is the mechanism for separating the object's behavior specific to a particular context (role) from the behavior specific to its class. Thus, overriding in owner class introduces a different way to organize the code defining the behavior. Looking at the examples within this article, one can see that it can make it easier to accomplish a variety of tasks, such as: to enforce class invariants concerning a member, as is done in the example with lee_jeans; to create an object managing two-way input and output, as is done in the example with visual_cash; to solve the updates issue, as is done in the example with working_girl; to write a class for immediate reuse without implementing all the minor details, as in the example with circular_gauge; to simplify and "objectify" the interface of a class, as in the example with int_property. | + | The main point of this article is to consider the nature of an '''object's behavior as consisting of two aspects''': the general behavior, provided by its class, and the behavior specific to a particular context in which the object is used. Conceptually, overriding in owner class is the '''''mechanism for separating the object's behavior specific to a particular context (role) from the behavior specific to its class'''''. Thus, overriding in owner class introduces a '''different way to organize the code defining the behavior'''. Looking at the examples within this article, one can see that it can make it easier to accomplish a variety of tasks, such as: |
| + | |||
| + | * to enforce class invariants concerning a member, as is done in the example with [[Definition_of_Overriding_in_Owner_Class#Lee_jeans|''lee_jeans'']]; | ||
| + | * to create an object managing two-way input and output, as is done in the example with [[Applications_of_Overriding_in_Owner#Visual_cash|''visual_cash'']]; | ||
| + | * to solve the updates issue, as is done in the example with [[Applications_of_Overriding_in_Owner#Working_girl|''working_girl'']]; | ||
| + | * to write a class for immediate reuse without implementing all the minor details, as in the example with [[Applications_of_Overriding_in_Owner#Circular_gauge|''circular_gauge'']]; | ||
| + | * to simplify and "objectify" the interface of a class, as in the example with [[Applications_of_Overriding_in_Owner#Int_property|''int_property'']]. | ||
| + | |||
| Overriding in owner class can affect the way you create the designs, particularly in how you set up objects of unrelated classes to work together; how the processing of an action is split from its cause; how reusable classes are written. I think that this approach will help minimize dependencies between classes; reduce their need for updates; avoid redundant subclassing and dynamic structures; provide fuller control over class members. The ease with which this mechanism fits into C++ and the fact that it does not, in my opinion, create inconsistencies in the language makes me think that it logically and usefully extends the language. | Overriding in owner class can affect the way you create the designs, particularly in how you set up objects of unrelated classes to work together; how the processing of an action is split from its cause; how reusable classes are written. I think that this approach will help minimize dependencies between classes; reduce their need for updates; avoid redundant subclassing and dynamic structures; provide fuller control over class members. The ease with which this mechanism fits into C++ and the fact that it does not, in my opinion, create inconsistencies in the language makes me think that it logically and usefully extends the language. | ||
| - | == Acknowledgment == | + | == Acknowledgments == |
| I am grateful to Vitaly Shmatikov for reviewing the draft of this paper and helping in its improvement. | I am grateful to Vitaly Shmatikov for reviewing the draft of this paper and helping in its improvement. | ||
| == References == | == References == | ||
| - | [1] A. Potekhin “Implementation of Overriding in Owner Class.” [[http://home.earthlink.net/~coem/oop]] | + | [1] A. Potekhin “[[Implementation_of_Overriding_in_Owner_Class|Implementation of Overriding in Owner Class]].” |
| [2] E. Gamma et al., “Design Patterns, Elements of Reusable Object-Oriented Software” | [2] E. Gamma et al., “Design Patterns, Elements of Reusable Object-Oriented Software” | ||
| - | '''[[Main_Page|Back to Main Page]]''' | + | '''[[Main_Page|To Main Page]]''' |
Current revision
The main point of this article is to consider the nature of an object's behavior as consisting of two aspects: the general behavior, provided by its class, and the behavior specific to a particular context in which the object is used. Conceptually, overriding in owner class is the mechanism for separating the object's behavior specific to a particular context (role) from the behavior specific to its class. Thus, overriding in owner class introduces a different way to organize the code defining the behavior. Looking at the examples within this article, one can see that it can make it easier to accomplish a variety of tasks, such as:
- to enforce class invariants concerning a member, as is done in the example with lee_jeans;
- to create an object managing two-way input and output, as is done in the example with visual_cash;
- to solve the updates issue, as is done in the example with working_girl;
- to write a class for immediate reuse without implementing all the minor details, as in the example with circular_gauge;
- to simplify and "objectify" the interface of a class, as in the example with int_property.
Overriding in owner class can affect the way you create the designs, particularly in how you set up objects of unrelated classes to work together; how the processing of an action is split from its cause; how reusable classes are written. I think that this approach will help minimize dependencies between classes; reduce their need for updates; avoid redundant subclassing and dynamic structures; provide fuller control over class members. The ease with which this mechanism fits into C++ and the fact that it does not, in my opinion, create inconsistencies in the language makes me think that it logically and usefully extends the language.
Acknowledgments
I am grateful to Vitaly Shmatikov for reviewing the draft of this paper and helping in its improvement.
References
[1] A. Potekhin “Implementation of Overriding in Owner Class.”
[2] E. Gamma et al., “Design Patterns, Elements of Reusable Object-Oriented Software”
