Applications of Overriding in Owner
From Andrey
| Revision as of 06:14, 3 February 2006 Andrey (Talk | contribs) ← Previous diff |
Revision as of 06:25, 3 February 2006 Andrey (Talk | contribs) Next diff → |
||
| Line 1: | Line 1: | ||
| Overriding in owner class can be helpful in the following situations: composing objects for collective work; customizing an object’s behavior for a particular use; propagating requests from components to aggregates; implementing control over manipulations on class members; and others. | Overriding in owner class can be helpful in the following situations: composing objects for collective work; customizing an object’s behavior for a particular use; propagating requests from components to aggregates; implementing control over manipulations on class members; and others. | ||
| We will consider the application of overriding in owner class to the following problems: | We will consider the application of overriding in owner class to the following problems: | ||
| + | |||
| #The problem of dependencies. | #The problem of dependencies. | ||
| #The problem of notifications. | #The problem of notifications. | ||
| - | #Code reusability. | + | #Code reusability.<br>…and to design cases: |
| - | …and to design cases: | + | |
| #Exporting a member in the interface. | #Exporting a member in the interface. | ||
| #Implementing the concept of a property in C++. | #Implementing the concept of a property in C++. | ||
| - | 1. Problem of Dependencies. Consider class F with members a and b, belonging to classes A and B respectively. Code C1 works with class B. When changes happen to F::b, F::a must be changed. This means that B, otherwise not tied with A, must know about A's existence to send a notification (the knowledge about A is brought into B, introducing member-to-member dependency). Alternatively, B must know about F's existence, to get F to notify F::a (the knowledge about F is brought into B, introducing member-to-owner dependency). The third solution is to rewrite code C1 to work with F instead of B (the knowledge about F is brought in C1, the interface of B or its part is included in the interface of F). | + | == Problem of Dependencies == |
| + | Consider class F with members a and b, belonging to classes A and B respectively. Code C1 works with class B. When changes happen to F::b, F::a must be changed. This means that B, otherwise not tied with A, must know about A's existence to send a notification (the knowledge about A is brought into B, introducing member-to-member dependency). Alternatively, B must know about F's existence, to get F to notify F::a (the knowledge about F is brought into B, introducing member-to-owner dependency). The third solution is to rewrite code C1 to work with F instead of B (the knowledge about F is brought in C1, the interface of B or its part is included in the interface of F). | ||
| + | |||
| + | [[Image:over1.gif|center]] | ||
| + | |||
| + | Problem: Developing a system from components, one has to make the code of some components depend on the existence, interface, and/or behavior of others. | ||
| + | Overriding in owner class (overriding methods of F::b in F) allows one to leave the code of B and C1 free from the need to know about owners and neighbors. It lets B remain simpler and more reusable, and leaves C1 unchanged. The details specific to F stay where they should: in class F. | ||
| + | Example. The visual_cash class is a screen representation of money, made of two parts: cash, providing data for the financial algorithms, and editbox, reflecting changes made by the algorithms and letting the user edit the amounts. Problem: changes made to one part must be reflected in the other. How to write these classes? | ||
| + | class visual_cash | ||
| + | { | ||
| + | public: | ||
| + | cash value; // data | ||
| + | editbox face; // representation | ||
| + | |||
| + | // overriden functions connect | ||
| + | // data with representation | ||
| + | |||
| + | void value::set(float l) | ||
| + | { | ||
| + | value.cash::set(l); face.set_text(value.get()); | ||
| + | } | ||
| + | |||
| + | void face::init() | ||
| + | { | ||
| + | face.set_text(value.get()); | ||
| + | } | ||
| + | |||
| + | void face::changed() | ||
| + | { | ||
| + | // when the user changes the text | ||
| + | // in the widget, value is updated. | ||
| + | value.cash::set(to_float(face.get_text())); | ||
| + | } | ||
| + | } visual_money; | ||
| + | |||
| + | |||
| + | // Pass visual_money.value to an algotithm, | ||
| + | // and if it is changed, the display is updated. | ||
| + | create_profit(&visual_money.value); | ||
| + | |||
| + | The components of visual_cash class are coordinated, however classes editbox, cash and the algorithms like create_profit() remain free from the need to know about each other. The composition-specific peculiarities remain in the composition class. | ||
| + | |||
| + | == Problem of Notifications == | ||
| + | |||
| + | There is a class B with a member a, belonging to class A. Code C1 works with objects of class A, in particular with the member of B. B should know what C1 does to B::a. Thus A should notify B about the operations performed on itself, or C1 should be changed to notify B about them. | ||
| + | |||
| + | [[Image:over2.gif|center]] | ||
| + | |||
| + | Problem: The code that makes changes must issue notifications about them. | ||
| + | Overriding in owner class (overriding methods of B::a in B) allows to one leave the code of A and C1 free from sending notifications to B about what happens to B::a. The code of A remains simpler and more reusable, C1 code does not change. | ||
| + | |||
| + | Example. Helen has a pager. She has to know about incoming calls. | ||
| + | // pager class | ||
| + | class motorola2sx | ||
| + | { | ||
| + | public: | ||
| + | virtual void call(); | ||
| + | }; | ||
| + | |||
| + | class working_girl | ||
| + | { | ||
| + | public: | ||
| + | motorola2sx pager; | ||
| + | |||
| + | // making owner know about call | ||
| + | void pager::call() { callback(); } | ||
| + | } Helen; | ||
| + | |||
| + | // calling Helen | ||
| + | Helen.pager.call(); | ||
| + | |||
| + | In this example, thanks to using overriding in owner class, notifications are completely absent. Reacting to the incoming calls is the responsibility of the pager owner, and, according to this, the code reacting to calls resides in the owner class. The motorola2sx class is focused on solving its own problems. The vendor of motorola2sx does not have to take care of the need to notify somebody about the calls. | ||
| - | [[Image:over1.gif]] | + | == Code Reusability == |
Revision as of 06:25, 3 February 2006
Overriding in owner class can be helpful in the following situations: composing objects for collective work; customizing an object’s behavior for a particular use; propagating requests from components to aggregates; implementing control over manipulations on class members; and others. We will consider the application of overriding in owner class to the following problems:
- The problem of dependencies.
- The problem of notifications.
- Code reusability.
…and to design cases: - Exporting a member in the interface.
- Implementing the concept of a property in C++.
Problem of Dependencies
Consider class F with members a and b, belonging to classes A and B respectively. Code C1 works with class B. When changes happen to F::b, F::a must be changed. This means that B, otherwise not tied with A, must know about A's existence to send a notification (the knowledge about A is brought into B, introducing member-to-member dependency). Alternatively, B must know about F's existence, to get F to notify F::a (the knowledge about F is brought into B, introducing member-to-owner dependency). The third solution is to rewrite code C1 to work with F instead of B (the knowledge about F is brought in C1, the interface of B or its part is included in the interface of F).
Problem: Developing a system from components, one has to make the code of some components depend on the existence, interface, and/or behavior of others. Overriding in owner class (overriding methods of F::b in F) allows one to leave the code of B and C1 free from the need to know about owners and neighbors. It lets B remain simpler and more reusable, and leaves C1 unchanged. The details specific to F stay where they should: in class F. Example. The visual_cash class is a screen representation of money, made of two parts: cash, providing data for the financial algorithms, and editbox, reflecting changes made by the algorithms and letting the user edit the amounts. Problem: changes made to one part must be reflected in the other. How to write these classes? class visual_cash { public: cash value; // data editbox face; // representation
// overriden functions connect // data with representation
void value::set(float l) { value.cash::set(l); face.set_text(value.get()); }
void face::init() { face.set_text(value.get()); }
void face::changed() { // when the user changes the text // in the widget, value is updated. value.cash::set(to_float(face.get_text())); } } visual_money;
// Pass visual_money.value to an algotithm,
// and if it is changed, the display is updated.
create_profit(&visual_money.value);
The components of visual_cash class are coordinated, however classes editbox, cash and the algorithms like create_profit() remain free from the need to know about each other. The composition-specific peculiarities remain in the composition class.
Problem of Notifications
There is a class B with a member a, belonging to class A. Code C1 works with objects of class A, in particular with the member of B. B should know what C1 does to B::a. Thus A should notify B about the operations performed on itself, or C1 should be changed to notify B about them.
Problem: The code that makes changes must issue notifications about them. Overriding in owner class (overriding methods of B::a in B) allows to one leave the code of A and C1 free from sending notifications to B about what happens to B::a. The code of A remains simpler and more reusable, C1 code does not change.
Example. Helen has a pager. She has to know about incoming calls. // pager class class motorola2sx { public: virtual void call(); };
class working_girl { public: motorola2sx pager;
// making owner know about call void pager::call() { callback(); } } Helen;
// calling Helen Helen.pager.call();
In this example, thanks to using overriding in owner class, notifications are completely absent. Reacting to the incoming calls is the responsibility of the pager owner, and, according to this, the code reacting to calls resides in the owner class. The motorola2sx class is focused on solving its own problems. The vendor of motorola2sx does not have to take care of the need to notify somebody about the calls.
