[ Pobierz całość w formacie PDF ]
.So, in a sense, private in Smalltalk is similar to protected in C++.Ah, but that would be too simple.Let's go back to C++.Say that I have another instance of Personal Customer, called Kendall.Kendall can access anymember of Martin that was defined as part of the Personal Customer class, whether public, private, or protected.Kendallmay also access any protected or public member of Martin that was defined within Customer.However, in Smalltalk,Kendall cannot access Martin's private instance variables- only Martin's public operations.In C++, you may access members of other objects of your own class in the same way that you access your ownmembers.In Smalltalk, it makes no difference whether another object is of the same class or not; you can access onlypublic parts of another object.Java is similar to C++ in that it offers free access to members of other objects of one's own class.Java also adds a newvisibility level, called package.A member with package visibility may be accessed only by instances of other classeswithin the same package.In keeping with our theme, to ensure that things are not too simple, Java slightly redefines protected visibility.In Java, aprotected member may be accessed by subclasses but also by any other class in the same package as the owning class.This means that in Java, protected is more public than package.Java also allows classes to be marked public or package.A public class's public members may be used by any class thatimports the package to which the class belongs.A package class may be used only by other classes in the same package.C++ adds a final twist.One C++ method or class can be made a friend of a class.A friend has complete access to allmembers of a class- hence, the phrase "in C++, friends touch each other's private parts."When you are using visibility, use the rules of the language in which you are working.When you are looking at a UMLmodel from elsewhere, be wary of the meanings of the visibility markers, and be aware of how those meanings canchange from language to language.I usually find that visibilities change as you work with the code.So, don't get too hung up on them early on.Chapter 7.Packages and CollaborationsOne of the oldest questions in software methods is: How do you break down a large system into smaller systems? Weask this question because as systems get large, it becomes difficult to understand them and the changes we make to them.Structured methods used functional decomposition, in which the overall system was mapped as a function and brokendown into sub-functions, which were broken down further into sub-sub-functions, and so forth.The functions were likethe use cases in an object-oriented system in that functions represented something the system as a whole did.Those were the days when process and data were separated.So in addition to a functional decomposition, there was alsoa data structure.This took second place, although some Information Engineering techniques grouped data records intosubject areas and produced matrices to show how the functions and data records interacted.It is from this viewpoint that we see the biggest change that objects have wrought.The separation of process and data isgone, and functional decomposition is gone, but the old question still remains.One idea is to group the classes together into higher-level units.This idea, applied very loosely, appears in many objectmethods.In the UML, this grouping mechanism is called the package.PackagesThe idea of a package can be applied to any model element, not just classes.Without some heuristics to group classestogether, the grouping becomes arbitrary.The one I have found most useful and the one stressed most in the UML is thedependency.I use the term package diagram for a diagram that shows packages of classes and the dependencies among them.Strictly speaking, a package diagram is just a class diagram that shows only packages and dependencies.I use thesediagrams quite a lot, so I name them package diagrams, but you should remember that that is my term, not an officialUML diagram name.A dependency exists between two elements if changes to the definition of one element may cause changes to the other.With classes, dependencies exist for various reasons: One class sends a message to another; one class has another as partof its data; one class mentions another as a parameter to an operation.If a class changes its interface, any message itsends may no longer be valid.Ideally, only changes to a class's interface should affect any other class.The art of large-scale design involvesminimizing dependencies; that way, the effects of change are reduced, and the system requires less effort to change.The UML has many varieties of dependency, each with particular semantics and stereotype.I find it easier to begin withthe unstereotyped dependency and use the more particular dependencies only if I need to.In Figure 7-1, we have domain classes that model the business, grouped into two packages: Orders and Customers.Bothpackages are part of an overall domain package.The Order Capture application has dependencies with both domainpackages.The Order Capture UI has dependencies with the Order Capture application and the AWT (a Java GUItoolkit).Figure 7-1.Package DiagramA dependency between two packages exists if any dependency exists between any two classes in the packages.Forexample, if any class in the Mailing List package is dependent on any class in the Customers package, a dependencyexists between their corresponding packages.There is an obvious similarity between these dependencies and compilation dependencies.In fact, there is a vitaldifference: With packages, the dependencies are not transitive.An example of a transitive relationship is one in which Jim has a larger beard than Grady, and Grady has a larger beardthan Ivar, so we can deduce that Jim has a larger beard than Ivar.To see why this is important for dependencies, look at Figure 7-1 again.If a class in the Orders package changes, thisdoes not indicate that the Order Capture UI package needs to be changed.It merely indicates that the Order Captureapplication package needs to be looked at to see if it changes.Only if the Order Capture application package's interfaceis altered does the Order Capture UI package need to change.In this case, the Order Capture application is shielding theOrder Capture UI from changes to orders.This behavior is the classic purpose of a layered architecture.Indeed, these are similar to the semantics of the Java"imports" behavior but not that of the C/C++ "includes" behavior.The C/C++ includes is transitive, which means thatthe Order Capture UI would be dependent on the Orders package.A transitive dependency makes it difficult to limit thescope of changes with compilation.(Although most dependencies are not transitive, you can create a particularstereotyped dependency that is.)Classes within packages can be public, private, or protected.So, the Orders package is dependent on the public methodsof the public classes in the Customers package.If you alter a private method, or a public method on a private class, in theCustomers package, none of the classes in the Orders package needs to change.A useful technique here is to reduce the interface of the package by exporting only a small subset of the operationsassociated with the package's public classes [ Pobierz całość w formacie PDF ]