Being able to view the state of an object is vitally important to class development, client use, and code maintenance. Being forced to index and display individual values is too tedious and far too time-consuming. MATLAB provides a decent display mechanism for scalars, arrays, and structures. Our classes deserve no less. As we have seen, MATLAB does not provide a good built-in display for objects, but now we know how to tailor functions to do whatever we want. All we need to know is the name of the built-in function.
1. DISPLAYING OBJECTS
MATLAB’s two primary display functions are display.m and disp.m. The biggest difference
between them is a connection between display and the semicolon operator. When a semicolon terminates a command, MATLAB does not call display. The opposite statement is also true. If a command does not end in a semicolon, MATLAB calls display. This behavior is very convenient and makes display a good overload candidate. Otherwise, all we will continue to see is the following cryptic message:
>> shape = cShape
shape =
cShape object: 1-by-1
Of course, we could also overload disp, sprintf, num2str, and evalc; however, these functions pale in convenience and importance to display . Developing a general solution for the other display functions does not add much value.
The function display is overloaded the same way any other function is overloaded. A customized member function named display.m is added to the class directory. After that, whenever display needs to operate on an object, the tailored version of display.m will be found. This is true when called directly as in display(shape), or indirectly by leaving off the semicolon.
1.1 WHAT SHOULD BE DISPLAYED?
The question of what to display might sound like a trick question, but it is not a trick. It isn’t easy to answer either. Unlike structures, objects have both public and private variables. Also different from structures, a public variable might be read-only, write-only, or read-write. There are also at least two audiences for the displayed information, clients and developers. The number of options makes it difficult to settle on a universal implementation for display.
In cShape, for example, developers might find it convenient to display stored HSV color values along with calculated RGB values. Developers and clients alike might like to see the value of mScale from time to time. Violating encapsulation by allowing client code to depend on private variables is a bad idea, but is it really a violation to allow a client to display internal states during client code debug and development? For some data and some developers, it might be okay. Once we nail down the kind of information to display, the implementation becomes easier. When deciding what should be displayed, there are at least three information categories or user-related topics to consider:
• value information for public member variables
• class membership lists and permissions
• class development and debug-related data
The first category represents a view that should look similar, if not identical, to a structure’s display. This helps extend the illusion of a class as a structure. Instead of structure elements, the display includes public member variables. We will call this the standard view. The second category represents a view that provides a brief summary of the interface, a summary that can often be used in lieu of help. The display for the second category should include a list of public member variables along with their type. A list of valid assignment values is also useful. The environment commands set(0) and get(0) can serve as a model for the display. The third category is intended primarily for class developers engaged in code development or maintenance.
This view is impossible to specify rigorously but should probably include all public member variables and often includes a large selection of private member variables. We will call this view developer view. For the first two views, MATLAB provides some guidance in the form of displays that exist elsewhere. For developer view, there really is no precedence. Developer view’s format is also more difficult to pin down because it is largely a matter of taste. Some developers prefer a standard structure-like display, some prefer a whos
-like format, and some prefer a format that provides even more detail. In fact, different formats can be useful during different stages of development. Developer view demands flexibility, and indeed, we can organize class variables and display to support flexibility.
Adding flexibility isn’t completely related to display. Part of the motivation is to reveal more ways that objects are fundamentally different from structures and develop some insight into how those differences might be exploited. Providing a design for display that allows almost unlimited flexibility serves many purposes. If we want to model the second-view category after get(0) and set(0), we need to develop tailored versions of these two functions. Once developed, get(cShape) and set(cShape) would display the appropriate lists. Like display, get and set are also members of the group of eight. The chapters in this section take on the group of eight one at a time. This chapter is devoted to display. Chapter 8 is devoted to get and set.
In any display, variables come in only four flavors:
• public member variables
• read-only public member variables
• write-only public member variables
• private member variables
There is almost universal agreement that standard view should include public member variables. After all, public variables are public for a reason and one of the best ways to advertise their availability is via display. Most also agree that the standard display should not include private variables. In some classes, it might make sense to include selected private variables, but generally, private variables are private for a reason. Omitting them from the standard view helps keep them private.
It is harder to reach a consensus on read-only and write-only variables. Part of the reason why it is difficult to decide is the observation that MATLAB’s structure display has no provision for such “oddly behaved” elements. We don’t have a firm foundation on which to base our opinions because read-only and write-only do not exist for structures. Perhaps the interface design can shed some light on these variables. In most situations, read-only and write-only permissions flow naturally from the class design and its interface definition. In a well-designed class with an intuitive interface, the idea of writing a value into a read-only variable should never occur. Even if the interface is not perfect, a client can display a read-only value even if it isn’t included in the standard display view.
This alone justifies including read-only variables in the standard view. Write-only variables are much less common. When the interface definition designates a variable as write-only, we should probably respect the designation. For this reason, we will not include write-only variables in the standard view. Modifications to standard display policy can always be addressed on a case-by-case basis.
1. DISPLAYING OBJECTS
MATLAB’s two primary display functions are display.m and disp.m. The biggest difference
between them is a connection between display and the semicolon operator. When a semicolon terminates a command, MATLAB does not call display. The opposite statement is also true. If a command does not end in a semicolon, MATLAB calls display. This behavior is very convenient and makes display a good overload candidate. Otherwise, all we will continue to see is the following cryptic message:
>> shape = cShape
shape =
cShape object: 1-by-1
Of course, we could also overload disp, sprintf, num2str, and evalc; however, these functions pale in convenience and importance to display . Developing a general solution for the other display functions does not add much value.
The function display is overloaded the same way any other function is overloaded. A customized member function named display.m is added to the class directory. After that, whenever display needs to operate on an object, the tailored version of display.m will be found. This is true when called directly as in display(shape), or indirectly by leaving off the semicolon.
1.1 WHAT SHOULD BE DISPLAYED?
The question of what to display might sound like a trick question, but it is not a trick. It isn’t easy to answer either. Unlike structures, objects have both public and private variables. Also different from structures, a public variable might be read-only, write-only, or read-write. There are also at least two audiences for the displayed information, clients and developers. The number of options makes it difficult to settle on a universal implementation for display.
In cShape, for example, developers might find it convenient to display stored HSV color values along with calculated RGB values. Developers and clients alike might like to see the value of mScale from time to time. Violating encapsulation by allowing client code to depend on private variables is a bad idea, but is it really a violation to allow a client to display internal states during client code debug and development? For some data and some developers, it might be okay. Once we nail down the kind of information to display, the implementation becomes easier. When deciding what should be displayed, there are at least three information categories or user-related topics to consider:
• value information for public member variables
• class membership lists and permissions
• class development and debug-related data
The first category represents a view that should look similar, if not identical, to a structure’s display. This helps extend the illusion of a class as a structure. Instead of structure elements, the display includes public member variables. We will call this the standard view. The second category represents a view that provides a brief summary of the interface, a summary that can often be used in lieu of help. The display for the second category should include a list of public member variables along with their type. A list of valid assignment values is also useful. The environment commands set(0) and get(0) can serve as a model for the display. The third category is intended primarily for class developers engaged in code development or maintenance.
This view is impossible to specify rigorously but should probably include all public member variables and often includes a large selection of private member variables. We will call this view developer view. For the first two views, MATLAB provides some guidance in the form of displays that exist elsewhere. For developer view, there really is no precedence. Developer view’s format is also more difficult to pin down because it is largely a matter of taste. Some developers prefer a standard structure-like display, some prefer a whos
-like format, and some prefer a format that provides even more detail. In fact, different formats can be useful during different stages of development. Developer view demands flexibility, and indeed, we can organize class variables and display to support flexibility.
Adding flexibility isn’t completely related to display. Part of the motivation is to reveal more ways that objects are fundamentally different from structures and develop some insight into how those differences might be exploited. Providing a design for display that allows almost unlimited flexibility serves many purposes. If we want to model the second-view category after get(0) and set(0), we need to develop tailored versions of these two functions. Once developed, get(cShape) and set(cShape) would display the appropriate lists. Like display, get and set are also members of the group of eight. The chapters in this section take on the group of eight one at a time. This chapter is devoted to display. Chapter 8 is devoted to get and set.
In any display, variables come in only four flavors:
• public member variables
• read-only public member variables
• write-only public member variables
• private member variables
There is almost universal agreement that standard view should include public member variables. After all, public variables are public for a reason and one of the best ways to advertise their availability is via display. Most also agree that the standard display should not include private variables. In some classes, it might make sense to include selected private variables, but generally, private variables are private for a reason. Omitting them from the standard view helps keep them private.
It is harder to reach a consensus on read-only and write-only variables. Part of the reason why it is difficult to decide is the observation that MATLAB’s structure display has no provision for such “oddly behaved” elements. We don’t have a firm foundation on which to base our opinions because read-only and write-only do not exist for structures. Perhaps the interface design can shed some light on these variables. In most situations, read-only and write-only permissions flow naturally from the class design and its interface definition. In a well-designed class with an intuitive interface, the idea of writing a value into a read-only variable should never occur. Even if the interface is not perfect, a client can display a read-only value even if it isn’t included in the standard display view.
This alone justifies including read-only variables in the standard view. Write-only variables are much less common. When the interface definition designates a variable as write-only, we should probably respect the designation. For this reason, we will not include write-only variables in the standard view. Modifications to standard display policy can always be addressed on a case-by-case basis.
Andy H. Register
0 comments: on "Displaying an Object’s State"
Post a Comment