Arguments and results

2020-03-01 202浏览

  • 1.Arguments and Results James Noble MRI, School of MPCE, Macquarie University, Sydney. kjx@mri.mq.edu.au July 31, 1997 Abstract If an object oriented program is a collection of communicating objects, then the objects' protocols de ne the languages the program speaks. Unfortunately, protocols are dicult to design in isolation, so many programs' protocols are not as well designed as they could be. This paper presents six patterns which describe how objects protocols can be designed or redesigned. By using these patterns, programs and designs can be made more simple, more general, and more easy to change. Introduction Object's protocols, also know as interfaces, are very important in object oriented design. An object's protocol is the face the object presents to other objects surrounding it. Using an object's protocol, other objects in the program can use the object as a server, thus accessing the behaviour the object provides. Similarly, an object can act as a client to other objects, in turn using their protocols to access their services. This paper presents six patterns for designing object oriented protocols (see Figure 1). The patterns focus on two aspects of protocol design the messages objects can receive, and the results objects return in response to the messages. These patterns do not attempt to describe novel techniques, rather, they present well-established solutions for object oriented design. These patterns should be useful for introducing the techniques to novice programmers, and for more experienced programmers, should illustrate when particular techniques are applicable and their relative strengths and weaknesses. These patterns are interrelated, but they do not form a whole language. Rather, the patterns are two fragments (Patterns about Arguments and Patterns about Results) which may one day form part of a larger pattern language. Each of the fragments has the same structure (see Figure 2) with one general pattern, and a couple of more speci c patterns which re ne the general pattern to handle specialised contexts. Figure 2 also illustrates two relationships between the patterns. One pattern can re ne another pattern, meaning one pattern is a more speci c version of the other. Alternatively, patterns can con ict, meaning that the patterns are mutually exclusive, each providing a di erent solution to a similar problem [24]. Forces Each of these patterns resolves a number of di erent forces, and some con icting patterns resolve similar problems in di erent ways. Many of the patterns consider the ease of reading or writing of a particular solution generally, solutions which are easy to write are more likely to be chosen by programmers, and solutions which are easy to read are likely to be easier to maintain. Since smaller, simpler programs are generally easier to read and write, the patterns are concerned with the complexity or size of a design, such as the number of messages an object understands, or the number of arguments needed by a message. Since much complexity cannot be avoided, the patterns prefer complexity to be handled once in server objects, rather than many times in every client object which uses the servers. 1
  • 2.Pattern Arguments Object Selector Object Curried Object Result Object Future Object Lazy Object Problem Solution How can you answer a question while you think about something else? How can you answer a question that is easy to answer now, but that may never be asked? Make a Future Object which computers the answer in parallel. How can you simplify a complex protocol that has a regular argument structure? Make an Arguments Object to capture the common parts of the protocol. Make a single message taking an object How can you simplify a protocol where several messages di er mainly in representing the message selector as an extra argument. their names? How can you simplify an extremely com- Send simpler messages to an intermediary plicated protocol? which elaborates them within its context. How can you manage a dicult answer to Make a Result Object the whole answer to a dicult question? the question. Make a Lazy Object which can answer the question later, if necessary. Figure 1: Summary of the Patterns Arguments Object Result Object Selector Object Curried Object Future Object Lazy Object Figure 2: The Structure of the Language Several patterns address the cohesion and coupling of the resulting designs, as designs with high cohesion within objects and low coupling between them are more exible, understandable, and easier to maintain. This is often related to whether a concept is represented explicitly by a single object in a design, or whether it is implicit in the communication between several objects. Representing a concept explicitly as an object generally makes it easier to identify the concept within the design, to change the implementation of the concept if necessary, and to reuse the concept elsewhere, especially if the object represents a real concept from the program's application domain. The patterns are also concerned with eciency the time and space cost of a design, and the number of objects it requires at runtime. Consequences A common principle underlies all these patterns that designs can often be improved by introducing ( nding) additional objects from within the program. At rst, the newfound objects seem out of place in the program, but as the program evolves, the found objects become better integrated into the design, and can be recognised as modelling concepts from the application domain. Because they nd new objects, these patterns tend to generate designs with many small, simple objects1, introducing an extra level of indirection, and imposing space and time costs at runtime. All these patterns simplify a design locally (for example, by changing one particular protocol) but impose global changes to the program (because extra objects are needed to implement the changed protocol). As a result, although objects may be easier to understand in isolation, the global design of the program may become confused. To quote AlanPerlis:In the long run every program becomes rococo then rubble. [19]. If these patterns are applied injudiciously they will accelerate this process. 1 This is not limited solely to these patterns. Many other patterns have this e ect, including those in Design Patterns [9] and Smalltalk Best Practice Patterns [5], as do Parnas's criteria for program decomposition [18]. 2
  • 3.Form The patterns are written in electric modi ed Portland form. Each begins with a question (in italics) describing a problem, followed by one paragraph describing the pattern's context, and a second describing the forces the pattern resolves. A boldface \Therefore:'>Therefore: