Implementation Terms


Those charged with the actual construction of software objects need vocabulary to support their work ”and support their object thinking ”while dealing with the details.

Method

Method is the name given to the block of code that is executed in response to a specific message. Each message in an object s protocol must have a corresponding method.

As noted earlier, at this level it can be difficult to differentiate, visually or  syntactically, an object method from a traditional subroutine, function, or procedure. Correct object thinking, however, will be reflected in the method collective. As an aggregate whole, object methods will vary in significant ways from a collection of routines or functions arrived at by applying traditional computer thinking while programming. For instance, there will be fewer object methods , and they will be simpler (on average) in their construction. Common control structures, such as Case statements and explicit looping constructs, will be absent (or if present, will be very few in number and will be used within an object and not for object coordination or scripting).

Some of the methods used by an object might be considered private , meaning that the object itself intends to use those methods and would prefer that they not be invoked by other objects. Public and private are concepts that apply to both methods and the messages that invoke those methods. An object will frequently send messages to itself, resulting in the execution of a private method, to obtain internally stored information or to obtain access to an object created in another method. Some languages enforce a distinction between public and private messages and their corresponding methods. Others do not, relying instead on the integrity of programmers to respect the object s design. [3]

Variable

A variable is a location or a container where an object might be located. Class variables are variables that are part of a class s permanent structure. Instance variables are variables that are part of an object s permanent structure.

Messages can be sent to a variable, in which case they are received and responded to by the object residing in that variable location ”the variable becomes an alias for the contents (object in residence) of the variable.

Late/Dynamic Binding

This is another programming term that assumes a particular importance in the world of objects. Type is a permanent [4] label attached to an object ”kind of like a brand or a tattoo ”that allows certain objects to be restricted to certain locations (variables) and allows a language compiler to enforce that restriction. In  some programming languages, the concept of type is minimized so that it becomes important only when the program is actually executing. Those languages are described as allowing dynamic , or late , binding. Not all programming languages support dynamic binding, and whether or not they should is a matter of much argument.

The value of dynamic binding lies in how it allows a developer to take advantage of the natural polymorphism of objects in a direct and intuitive fashion. It is possible, for instance, to create a variable, DisplayQueue , that will at various times contain a text object, or a graphic object, or even a movie clip object. I can send the display message to the DisplayQueue variable, and whichever object is occupying the variable at that point in time will receive the message, interpret it (polymorphism), and display itself. I do not worry about the heterogeneous content of the variable.

A disadvantage arises from the possibility that I accidentally send an object to DisplayQueue that does not know how to display itself, does not respond to the display message. This can be prevented by asking any object seeking entry to DisplayQueue whether it understands the display message. If it does, it s allowed in; if not, it s refused entry.

The drawback of dynamic binding is the possibility that an inappropriate object might come to occupy the variable, receive a message that it does not understand, and cause the program to fail. In type-safe languages, erroneous assignment errors of this kind will be detected by the compiler, flagged, and corrected by the programmer before the program is allowed to execute. Unless, of course, you cast types and get something like a Java class cast exception error ”the equivalent of Smalltalk s does not understand error.

Solving this dilemma in a dynamically bound language is straightforward. If the situation requires, I merely ask any object that seeks to occupy a variable whether it understands a particular message or whether it s an instance of a particular class, and I grant or deny residency based on its answer. This is extra work, of course, and can have an impact on performance. Deciding when I need to employ this kind of type checking is an important part of design and of object thinking. The justification for allowing dynamic typing and inserting explicit class membership checking when needed should be empirical. Excepting the human interface, the probability of encountering a type error should be quite low. If the consequences of error are minimal, the need to insert extra code to check typing might not be needed. Simpler designs and implementations should make implicit typing so obvious that programmer error is minimized. The user interface will almost always have to enforce the equivalent of type checking for every value entered, but once a value is in the system, it should not need to be rechecked. Typing is sufficiently restrictive that programmers will employ features such as casting to escape the restrictions. How many of which kind of errors, with what frequency, can be prevented (or caused) by employing strict typing and allowing means for avoiding type restrictions (casting)?

The merits of early and late binding are a source of considerable argument. We need not be concerned with that here. It must be noted, however, that object thinking is better reflected in an environment that allows dynamic binding. In the spirit that everything is an object, variables too are objects and should have the responsibility of maintaining their integrity instead of giving that responsibility to another object such as a compiler.

[3] Languages such as C++ and Java also allow for protected messages/methods. This is a way to allow outside objects to send such messages (invoke such methods) but restrict the number of outside objects having that privilege. C++ also allows for friends , objects that have access to the private messages/methods of other objects.

[4] We are ignoring, for the moment, the possibility of casting types.




Microsoft Object Thinking
Object Thinking (DV-Microsoft Professional)
ISBN: 0735619654
EAN: 2147483647
Year: 2004
Pages: 88
Authors: David West

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net