31 Frameworks for Understanding

31 31 Frameworks for Understanding It is unlikely that you will learn how to use a "framework class library" in any of your computer science courses at university. Frameworks don't possess quite the social cachet of "normal forms for relational databases", "NP complexity analysis", "LR grammars", "formal derivation of algorithms", "Z specification" and the rest. You might encounter "Design Patterns" (which relate to frameworks) in an advanced undergraduate or graduate level course; but, on the whole, most universities pay little regard to the framework-based development methodologies. However, if you intend to develop any substantial program on your personal computer, you should plan to use the framework class library provided with your development environment. As illustrated by the simple "RecordFile" framework presented in the last chapter, a framework class library will embody a model for a particular kind of program. Some of the classes in the framework are concrete classes that you can use as "off the shelf" components (things like the MenuWindow and NumberDialog classes in the RecordFile framework). More significant are the partially implemented abstract classes. These must be extended, through inheritance, to obtain the classes that are needed in an actual program. Of course, the framework-provided member functions already define many standard patterns of interactions among instances of these classes. Thus, in the RecordFile framework, most of the code needed to build a working program was already provided by the Application, Document, and Record classes along with helpers like RecordWindow. If you can exploit a framework, you can avoid the need to reimplement all the standard behaviours that its code embodies. The "typical framework" The commonly encountered frameworks provide a model for what might be termed The "classic "the classic Macintosh application". With some earlier prototypes at Xerox's Macintosh application" research center, this form of program has been around since 1984 on the Macintosh (and, from rather later, on Intel-Windows machines). It is the model embodied in 1134 Frameworks your development environment, in your word processor program, your spreadsheet, your graphics editor, and a host of other packages. Application, You have an "Application". It creates "Documents" (which can save their data Document, View, and to disk files). The contents of documents are displayed in "Views" inside Window "Windows". (On the Macintosh, separate documents have completely separate windows. On a Microsoft Windows system, an "Application" that supports a "multiple document interface" has a main window; the individual documents are associated with subwindows grouped within this main window). The same data may appear in multiple views (e.g. a spreadsheet can display a table of numbers in one view while another view shows a pie-chart representing the same values). "Pick and object, give The manuals for these programs typically describe their operation in terms of it a command" "picking an object, and giving it a command". The manual writers are thinking of "objects" that are visual elements displayed in the views. In most cases, these will represent actual objects as created and manipulated by the program. "Picking an object" generally involves some mouse actions (clicking in a box, or dragging an outline etc). The bit about "giving a command" generally refers to use of a menu, or of some form of tool bar or tool palette. For instance, in your word processor you can "pick a paragraph" and then give a command like "set 'style' to 'margin note'"; while in a drawing program you can pick a line and select "Arrows… at start". Such commands change attributes of existing objects. New objects can be created in a variety of ways, e.g. drawing, typing, or menu commands like "paste". "Network" data Using the editing tools associated with a program, you build an elaborate structures "network" data structure. Most of the programs will represent their data in memory as a network of separate "objects" interlinked via pointers. If the program is a word processor, these objects might include "text paragraphs", "pictures", "tables", "style records", "format run descriptors" (these associate styles with groups of characters in paragraphs, they link to their paragraphs via pointers), and so forth. The sequence of "paragraphs" and "pictures" forming a document might be defined by a list. A draw program will have as basic elements things like lines, boxes, ovals; the basic components of a picture are instances of these classes (each instance having its own attributes like colour, size, position). Individual elements can be grouped; such groups might be represented by lists. Usually, a draw program allows multiple groups, so its primary data structure might be a list of lists of elements. The ordering in the top level list might correspond to the front to back ordering in which items are drawn. A spreadsheet might use an array of cells whose contents are pointers to data objects like text strings, numbers, and "formulae objects". There would be other data structures associated with the array that help identify relationships amongst cells so that if a number in a cell gets changed, the dependent formulae are recalculated. This network data structure (or a printout of a visual representation) might be all that the program produces (e.g. word processor and draw programs). In other cases, like the spreadsheet, you want to perform calculations once the data are entered. Introduction 1135 Example frameworks The frameworks that you are most likely to encounter are, for the Macintosh: • Symantec's Think Class Library (TCL) Version 2 • Apple's MacApp Version 3.5 and for Intel-Windows: • Borland's Object Windows Library (OWL) Version 2 • Microsoft Foundation Classes (MFC) Version 1.5 Several other companies have competing products for the Intel-Windows environment. There are substantial similarities among these frameworks because they all Similar underlying attempt to model the same type of interactive program and all have been model influenced, to varying degrees, by the earlier experimental MacApp 1 and MacApp 2 libraries. (The Borland framework includes a slightly simpler Program-Window model in addition to the " standard" Application-Document-Window-View model. If you are using the Borland framework, you will probably find it worthwhile using the simpler Program-Window model for the first one or two programs that you try to implement.) A similar class library exists for Unix. This ET++ class library is available free via ftp on the Internet (on Netscape, try ftp://ftp.ubilab.ubs.ch/pub/ET++/). It might be possible to adapt ET++ for use on a Linux environment. There are "problems" with the C++ code in all these libraries. The Borland Some C++ limitations library probably makes the best use of the current C++ language. The ET++ library was written several years ago, before C++ supported either multiple inheritance or templates and, in some respects, its coding styles are dated. The Symantec compiler does not yet support recent language features like exceptions (the library fakes exception handling with the aid of various "macros"). The dialect of C++ used for MacApp is slightly non-standard (it had to be changed so that the library could support use from dialects of Pascal and Modula2 as well as C++). The MacApp system is also relatively expensive compared with the other products and its development environment, although having some advantages for large scale projects, is not nearly as convenient to use as the Integrated Development Environments from Symantec, Borland, or Microsoft. The early class libraries (MacApp and ET++), and also MFC, have essentially Library structures all their classes organized in a tree structured hierarchy. This style was influenced by earlier work on class libraries for Smalltalk. There are some disadvantages with this arrangement. "Useful" behaviours tend to migrate up to the base class of the hierarchy. The base "TObject" class acquires abilities so that an instance can: transfer itself to/from disk, duplicate itself, notify other dependent objects any time it gets changed, and so forth. All classes in the hierarchy are then expected to implement these behaviours (despite the fact that in most programs Window objects never get asked to duplicate themselves or transfer themselves to disk). This is one 1136 Frameworks the factors that contribute to complexity of the frameworks (like the three hundred member functions for a scroll bar class). The structure of the "RecordFile" framework, a "forest" of separate trees, is similar to that of the more modern frameworks. These more modern frameworks can still provide abstractions representing abilities like persistence (the ability of an object to transfer itself to/from a disk file). In modern C++, this can be done by defining a pure abstract (or maybe partially implemented abstract) base class, e.g. class Storable. Class Storable defines the interface for any object that can save itself (functions like DiskSize(), ReadFrom(), WriteTo()). Persistent behaviours can be acquired by a class using multiple inheritance to fold "storability" in with the class's other ancestry. In the older frameworks, the "collection classes" can only be used for objects that are instances of concrete classes derived from the base "TObject" class. More modern frameworks use template classes for their collections. The frameworks are evolving. Apart from ET++, each of the named frameworks is commercially supported and new versions are likely to appear. This evolutionary process tends to parallelism rather than divergence. Clever features added in the release of one framework generally turn up in the following releases of the competitors. Tutorial examples It will take you at least a year to fully master the framework library for your development environment. But you should be able to get their tutorial examples to run immediately and be able to implement reasonably interesting programs within two or three weeks of framework usage.

Load more