Smalltalk and Object Orientation: an Introduction - Free

More documents

Recommendations

Info

geographic information system. These facilities could then be used to construct a concrete payroll (or GIS) system with the features required by a specific organization. • Domain frameworks encapsulate expertise in a particular problem domain. These frameworks encompass a vertical slice of functionality for a particular client domain. Examples of domain frameworks include: a control systems framework for developing contro l applications for manufacturing systems or drawing frameworks such as HotDraw, Unidraw for C++/X windows and DRAW_Master for C++/OS 2 and Windows environments. • Support frameworks provide system -level services, such as file access, distributed computing support, or device drivers. Application developers typically use support frameworks directly or use modifications produced by system providers. However, even support frameworks can be customized - for example when developing a new file system or device driver. Since frameworks are reusable designs, not just code, they are more abstract than most software which makes documenting them more difficult. Documentation for a framework has three purposes and patterns can help to fulfill each of them. Documentation must provide: 1. the purpose of the framework, 2. how to use the framework, 3. the detailed design of the framework. 21.2.2 Designing object-oriented frameworks The process of designing and implementing frameworks is not trivial and is, in many ways, harder than designing and implementing a one off application. This is because the framework needs to be complete, robust, generic, easy to use, extensible and flexible if it is to be effective: • Complete. A framework must provide all the infrastructure required to construc t applications. This includes documentation, concrete examples as well as the underlying skeleton of the framework. If any of these are missing (in particular the underlying skeleton) then this will act as an impediment to the adoption of the framework. • Robust. A framework that is not robust will soon be ignored as users will not want to have to debug the framework as well as their own code. • Generic. A framework that is not generic (relative to its application area) will be difficult to apply except in very specific ways. This can reduce the incentive for organizations to adopt a framework. • Easy to use . A framework which is difficult to use will not be adopted as few developers have the time to gain the necessary understanding to take advantage of such a framework. • Extensible. Users of the framework should find it easy to add and modify default functionality. That is, the framework should provide hooks so that users can apply the framework in different ways. • Flexible. One of the claimed benefits of frameworks is that they can be applied and used in ways which were not envisaged by their creators. They therefore need to be flexible. The first step in developing a framework is to analyze the application problem domain such that you know the requirements of any frameworks, the types of frameworks that would be useful and how they might be used. For example, look for the types of subsystems which are built repeatedly. A pseudo natural language parser might be a common subsystem within a range of diagnostic tools. The next step involves identifying what is common about these systems and what is different. This allows the identification of the primary abstractions for the framework. These are the components which are constant across applications (even though they ma y have different names in these different applications). Note that it is often easiest to work bottom up in identifying these abstractions (in some cases the designs of the system might be the best starting points and in others the source code). The third step involves taking these abstractions and constructing a skeleton for the framework. This skeleton should provide the basic infrastructure (comprised of the abstract concepts) for the framework. This is a bit like attempting to produce a set of abstract classes and their interactions for some application, without filling out all (or most) of the concrete classes. 172
As the framework takes shape you should be continually attempting to refine it by adding more default behavior, more hooks into it as well as additional ways for users to interact with it. You will also need to produce concrete instantiations of the framework to test its functionality and to customizability. These example instantiations should be included with the framework as part of the deliver ed product (whether it is delivered internally or externally to your organization). The whole development process is extremely iterative but is by necessity subject to the strictest of software engineering practice. In addition suitable documentation of the framework is essential (and this is where design patterns come into their own) from design, implementation and user perspectives. Finally, some useful general comments about framework development include: • Develop frameworks by examining existing applications. • Develop small focused frameworks (breaking down larger frameworks when the opportunity to do so is identified). • Build frameworks using an iterative process prototyping how the frameworks will be used all the time. • Always look out for additional fun ctionality for the framework. For such functionality, determine whether it should be a default behavior of the framework or whether a hook should be provided to allow a user to implement it. • Good documentation is essential and should include sample instant iations of the framework, descriptions of the framework architecture, descriptions of the framework and its intent, guidelines on using the framework and cookbook examples for particular operations. 21.2.3 What is a design pattern? Design patterns capture expertise in building object oriented software [Gamma et al 1993; Johnson 1992; Beck and Johnson 1994]. A design pattern describes a solution to a recurring design problem. It also contains information on the applicabili ty of a pattern, the trade offs which must be made and any consequences of the solution. Books are now appearing which present such design patterns for a range of applications. For example, [Gamma et al, 1995] is a widely cited book which presents a cat alog of 23 design patterns. Design patterns are extremely useful for both novice and experienced object oriented designers. This is because they encapsulate extensive design knowledge and proven design solutions with guidance on how to use them. Reusing common patterns opens up an additional level of design reuse, where the implementations vary, but the micro -architectures represented by the patterns still apply. There are potentially very many design patterns available to a designer. A number of these patterns may superficially appear to suit their requirements, even if the design patterns are available on -line (via some hyper text style browser) it is still necessary for the designer to search through them manually, attempting to identify the design which best matches their requirements. In addition, once they have found the design which they feel best matches their needs, they must then consider how to apply it to their application. This is because a design pattern describes a solution to a particular design problem. This solution may include multiple trade offs which are contradictory and which the designer must choose between, although some aspects of the system structure can be varied independently (although some attempts have been made to automate this process for example [Budinsky et al 1996]). Patterns seem to be exceptionally well suited for documenting frameworks. They certainly provide guidance on how to use a framework, the purpose of the framework, they can also include concrete examples and can be used to document the design of the framework. 21.2.4 Pattern templates The pattern template used in [Gamma et al , 1995] provides a standard structure for the information which comprises a design pattern. This makes it easier to comprehend a design pattern as well as providing a concrete structure for those defining new patterns. Gamma’s book [Gamma et al , 1995] provides a detailed description of the template; only a summary of it is presented in Table 21.1. Patterns are best suited for teaching how to use a framework, but with care they can meet all three purposes identified earlier. By describing the design of a framework in terms of patterns, you describe both the design and the rationale behind the design. As patterns also show how to use the framework for 173
Page 1 and 2:
Smalltalk and Object Orientation: A
Page 3 and 4:
Chapter 7: Smalltalk Constructs Thi
Page 5 and 6:
The user interface construction fac
Page 7 and 8:
Preface 1. INTRODUCTION TO OBJECT O
Page 9 and 10:
12.5 A CLASS SIDE METHOD...........
Page 11 and 12:
27.3 VISUALWORKS WINDOW PAINTING TO
Page 13:
Part One Introduction to Object Ori
Page 16 and 17:
interfaces between different parts
Page 18 and 19:
een to ease the transition from one
Page 20 and 21:
encapsulation. Attempting to introd
Page 22 and 23:
is a controversial subject which is
Page 24 and 25:
will become second nature to many o
Page 26 and 27:
or return something. It has since b
Page 28 and 29:
defining the behavior of different
Page 30 and 31:
In time most developers start to ac
Page 32 and 33:
2.4.3.4 Smalltalk environments are
Page 34 and 35:
3. Constructing an Object Oriented
Page 36 and 37:
Wash wipe switch Wiper motor Relay
Page 38 and 39:
Point 2 above is more complicated.
Page 40 and 41:
services working? working? working?
Page 42:
Part Two The Smalltalk Language 42
Page 45 and 46:
other systems. As the browsers, ins
Page 47 and 48:
VisualAge (a version of Smalltalk w
Page 49 and 50:
4.5.2 The VisualWorks Launcher and
Page 51 and 52:
Class categories. These are group s
Page 53 and 54:
5. A Little Smalltalk 5.1 Introduct
Page 55 and 56:
Notifiers can be displayed under a
Page 57 and 58:
These concepts of messages, receive
Page 59 and 60:
Select the “Debug” option. This
Page 61 and 62:
6. Smalltalk Building Blocks 6.1 In
Page 63 and 64:
6.3.1 Class definitions In Smalltal
Page 65 and 66:
Object Class1 Class 2 method search
Page 67 and 68:
“Now calculate y “ y := x * 23.
Page 69 and 70:
7. Smalltalk Constructs 7.1 Introdu
Page 71 and 72:
They are more efficient for storage
Page 73 and 74:
7.5.3 true, false and nil variables
Page 75 and 76:
anArray at: 1 max: 10. This will tr
Page 77 and 78:
Figure 8.1: Defining a new class 8.
Page 79 and 80:
this convention at the moment, howe
Page 81 and 82:
9. Control and Iteration 9.1 Introd
Page 83 and 84:
9.3.3 Block temporary variables Blo
Page 85 and 86:
The brackets round the 1 to: 10 are
Page 87 and 88:
OrderedCollection class (respective
Page 89 and 90:
holding other objects. Typically, c
Page 91 and 92:
| temp | temp := Set new. temp add:
Page 93 and 94:
Next we will define a message proto
Page 95 and 96:
11. Further Collection Classes 11.1
Page 97 and 98:
for (i = 0; i
Page 99 and 100:
x inspect. This has some similariti
Page 101 and 102:
11.9.3 The reject: message The reje
Page 103 and 104:
• asSortedCollection. This create
Page 105 and 106:
Figure 12.2: The Organizer class de
Page 107 and 108:
12.6 The private-updating protocol
Page 109 and 110:
do: [:item | Transcript show: item
Page 111 and 112:
13. Streams and Files 13.1 Introduc
Page 113 and 114:
Notice that in this example we used
Page 115 and 116:
to reconstruct the data into object
Page 117 and 118:
1. The ability to save the current
Page 119 and 120:
14.3 The class Date Class Date, a s
Page 121 and 122: aCharacter isAlphabetic. aCharacter
Page 123 and 124: Breakpoints may be placed in a me t
Page 125 and 126: If the file does not exist you will
Page 127 and 128: Figure 15.4: Creating a project To
Page 129 and 130: Part Three Object Oriented Design 1
Page 131 and 132: 16. Object Oriented Analysis and De
Page 133 and 134: devolved amongst the objects). This
Page 135 and 136: driving force behind the whole of t
Page 137 and 138: 17. The Unified Modeling Language 1
Page 139 and 140: Deployment diagrams . Deployment di
Page 141 and 142: Window abstract +size : Area = (10,
Page 143 and 144: Micro Computer 1.. * Monitor System
Page 145 and 146: connectedTo * Lamp * Weight Sensor
Page 147 and 148: 18. UML: Dynamic Modeling And Deplo
Page 149 and 150: edisplay() Controller window A Wind
Page 151 and 152: 18.2.3.1 A start point A start poin
Page 153 and 154: etween nodes and their stereotype.
Page 155 and 156: OMT is a prescriptive method, it pr
Page 157 and 158: confirming the users’ needs, thei
Page 159 and 160: 19.3.2.2 Prepare a data dictionary
Page 161 and 162: car, truck and bus under a supercla
Page 163 and 164: 20.2.1.3 Prepare sequence and colla
Page 165 and 166: 20.2.2.5 Specify optimization crite
Page 167 and 168: are therefore concurrent and can be
Page 169 and 170: 20.3.2.3 Design optimization The an
Page 171: 21. Frameworks and Patterns for Obj
Page 175 and 176: about a set of classes, than to att
Page 177 and 178: instanceVariableNames: '' classVari
Page 179 and 180: 21.5.5 Running the editor You have
Page 181 and 182: Part Four Testing and Style 181
Page 183 and 184: made worse, because the symbol held
Page 185 and 186: 22.3.2 Incremental testing Incremen
Page 187 and 188: control the execution of the method
Page 189 and 190: 22.7.2 The Perform: message The per
Page 191 and 192: From the scenario that a person mig
Page 193 and 194: 23.4 Self testing An approach, sugg
Page 195 and 196: 24. Smalltalk Style Guidelines 24.1
Page 197 and 198: 24.2.4 Adding variables to system c
Page 199 and 200: should use a dictionary to hold the
Page 201 and 202: • A method should only send messa
Page 203 and 204: Table 24.2: Class message categorie
Page 205 and 206: 25. The Perform and Dependency Mech
Page 207 and 208: • Inheritance (class to class rel
Page 209 and 210: You can find the methods which impl
Page 211 and 212: These messages are sent automatical
Page 213 and 214: 26. The Model-View-Controller Archi
Page 215 and 216: and wit hdrawals and requests for t
Page 217 and 218: Figure 26.5: Part of the Controller
Page 219 and 220: model 4. update 1. balance (view) 0
Page 221 and 222: displayed. The second component add
Page 223 and 224:
27. Graphical User Interface Constr
Page 225 and 226:
27.3.1 Palette The Palette tool pro
Page 227 and 228:
uild a running user interface from
Page 229 and 230:
names) and the actions for buttons
Page 231 and 232:
Edit button, then the user interfac
Page 233 and 234:
27.11 Visual reuse The aim of visua
Page 235 and 236:
Figure 27.17: Defining the parent c
Page 237 and 238:
important, as these facilities hand
Page 239 and 240:
28.3 The AddressBook class 28.3.1 T
Page 241 and 242:
The aspect methods can then be simp
Page 243 and 244:
the name is in the address book, it
Page 245 and 246:
29.2 The custom view widget 29.2.1
Page 247 and 248:
DrawingView model SmallDraw drawing
Page 249 and 250:
The action of adding a new graphic
Page 251 and 252:
The next method we shall consider i
Page 253 and 254:
In the updating protocol we need to
Page 255 and 256:
The displaying protocol contains th
Page 257 and 258:
30. Memory Management and Garbage C
Page 259 and 260:
30.3.3 PermSpace This is used to ho
Page 261 and 262:
31. Concurrency in Smalltalk 31.1 I
Page 263 and 264:
The Semaphore class provides facili
Page 265 and 266:
Once the process wakes up it can de
Page 267 and 268:
31.4.3 Acknowledgments Acknowledgme
Page 269 and 270:
“There are two kinds of objects i
Page 271 and 272:
Object Object class Collection Coll
Page 273 and 274:
ehavior, but from the point of view
Page 275 and 276:
32.5.5 The whole enchilada Behaviou
Page 278 and 279:
33. The Future for Object Technolog
Page 280 and 281:
solutions are needed which suit the
Page 282 and 283:
scripting and query language to use
Page 284 and 285:
34. Appendix: The Smalltalk Languag
Page 286 and 287:
A capitalization convention is used
Page 288 and 289:
• marries: is the message selecto
Page 290 and 291:
Array OrderedCollection SortedColle
Page 292 and 293:
[Coleman et al 1994] D. Coleman, P.
Page 294 and 295:
OOPSLA/ECOOP’90, Joint Conference
Page 296 and 297:
detect.............................
Page 298:
True...............................
show all

Smalltalk and Object Orientation: an Introduction - Free

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?