[ Pobierz całość w formacie PDF ]
.Methods and functions are scopesfor the local variables declared within them.Over and over again we see the samemechanism at work in many different language features.To access a specific ele-ment, we state precisely which one we want by providing the scopes from the topdown.Unfortunately, it isn t always this simple.Sometimes these scopes are implicit,and we can leave them off, such as when referring to a local variable within a methodor to another member within a class.Furthermore, despite their common behav-ior, these scopes can have different syntaxes through which they are accessed.Forinstance, in C++, to access theMenuclass within theGraphicalUIElementsnamespace, we would state it asGraphicalUIElements::Menu, using a dou-ble colon.Given an instance of that class, however, we would access its list of menuitems asaMenu.theItems, using a dot operator.Both of these techniques specifywhich element we wish to select from a scoping element, but they do so in differentways.This text defines a single way in which we can treat all scoping, regardless ofhow it is implemented for specific language features within specific languages.Consider classAthat has a methodf, and classBthat has a methodg, as shownin UML in Figure 2.4 and in code in Listing 2.1.Ahas a fieldbof typeB.In themain()body, an instanceaof typeAis instantiated, and thena.f()is invoked.The methodf()is scoped by the objecta.In object-oriented languages, functionsand methods are always enclosed by some scope, even if the scope is implicit.Even in C++ global functions and fields can be considered as thoughthey reside inside an invisible and implicit object representing a global names-pace, which is how the runtime effectively treats them.Check Clause 3.3.6[basic.scope.namespace], paragraph 3, of the 2011 C++ ISO Standard WorkingDraft [6] for confirmation.Further, the use of file-scoped elements in C++, thosedeclared global and static, is now discouraged by the conventional wisdom in favorA Bg()b : Bf() h()b.g()Figure 2.4 A simple method call as UML.From the Library of Santiago Itzcoatl Salinas Reyna 24Chapter 2: Elemental Design PatternsListing 2.1 A simple method call as pseudocode.1 class A {B b;3 f() {b.g();5 };};7class B {9 g() {};h() {};11 };13 main() {A a;15 a.f();};of unnamed namespaces, which perform the same function more explicitly.In otherwords, each translation unit gets its own object for scoping, and the fact that thescope has no name means it can t be used outside that translation unit.Again,objects are being used to scope and wrap elements that have previously been con-sidered as freely roaming.Getting back to the code example,a.f()in turn callsb.g(), and a rela-tionship exits between those two methods.The relationship betweenaandf, oneof enclosure or scoping, is contextual.It helps specify which method we are talk-ing about.A similar relationship exists betweenbandg.The call froma.f()tob.g(), however, is not just contextual, it is the primary relationship between thosetwo methods.In other words, this is the relationship we re interested in, but wehave to use scoping to get there.Scoping relationships help us refine our view to a particular design element.Weneed exactly two such design elements to form the single relationship described inan EDP.There may be a number of scoping relationships that set up the final singlerelationship we are interested in, but we are not immediately concerned with them.They are part of the description of the elements of programming that comprisethe endpoints of the relationship we wish to work with.Returning to our earliermetaphor of housing styles and design, the scoping elements are a bit like statingthat a piece of wood is a two-by-four or a half-inch-thick sheet of bias-grain ply-wood.That information doesn t tell us how to orient one to the other or where todrive the nails.Scoping provides a context to help define what an element is, but itdoesn t do much to explain how that element relates to others in the system.We can now tweak our question of whether we ve reached our decompositiongoal to, Does this embody more than one relationship of interest?, which gets usFrom the Library of Santiago Itzcoatl Salinas Reyna 252.2 The Where, the Why, the Howcloser to our goal.Now we just have to determine what a relationship of interestis.So far, we ve described scoping relationships, which include class ownership ofmethods and fields, as well as namespaces, packages, and all the other groupingtechniques available in programming, and we stated that we re not interested inthem at the moment.Let s consider instead what remains that we could form rela-tionships between.What remains are classes, their fields and methods, and little else.One itemseems to be missing from the list: objects.It is object-oriented programming, afterall! We ll add objects to the list for completeness, and later we ll show how they recentral to this approach.(For a formal explanation, see the appendix.) For now, wehave these four kinds of programmatic entities on our list: objects, methods, fields,and classes, or types.This may seem like an odd thing to do, but it actually makessolid sense.We don t call them classes, because not every object-oriented language hasclasses, but every object-oriented language has types.Remember that we re look-ing to describe design patterns in a way that can cross language borders, so we regoing to be looking for features that are common to, and a requirement for, eachand every object-oriented language.So how do we make the transition from classes,which most people are familiar with, to a more classically pure object-orientedapproach? It s not that complex, really: it simply involves splitting a class into itsconstituent parts.A class is an interesting beast in that it is so common in most object-orientedlanguages that many students and developers consider it a primary and necessaryelement.The reality, from a strictly object-oriented viewpoint, is that it is not.Somelanguages, such as Self and Lua, don t even have the concept of a class.Instead,they rely on prototyping, cloning, and other actions on objects to perform the samefunctions.It s not just esoteric languages that exhibit this use of objects in placeswhere most languages use classes, as a variety of this usage can be seen in JavaScript.Even Smalltalk, arguably the progenitor of most object-oriented languages, has aquite different implementation and understanding of a class even though the sameterm is used.In general, a class in current common object-oriented languages such as C++and Java performs two duties
[ Pobierz całość w formacie PDF ]