-软件工程-15-面向对象信息隐藏课件.ppt

1、计算与软件工程II Ch15 “面向对象”的信息隐藏丁二玉南京大学软件学院Information Hiding nEach module hides the implementation of an important design decision (secrets) so that only the constituents of that module know the details3Design Secrets need to hidenPrimary Secret: Responsibility ChangenHidden information that was specifie

2、d to the software designernFrom SRSnSecondary Secret: Implementation ChangenThe implementation decisions made by the designer when implementing the module designed to hide the primary secretn变化；Main Contents1.Encapsulation1.What should be hiding?2.How to hiding change?Encapsulation (1)nEncapsulation

3、 allows the programmer to group data and the subroutines that operate on them together in one placenResponsibilityEncapsulation (2)nhide irrelevant details from the user na class can be divided into two parts, the user interface and the implementation.nThe interface is the visible surface of the cap

4、sule.qdescribes the essential characteristics of objects of the class which are visible to the exterior worldnThe implementation is hidden in the capsule.qThe implementation hiding means that data can only be manipulated, that is updated, within the class, but it does not mean hiding interface data.

5、New View of EncapsulationnOld/Beginner/Implementation view of encapsulation: hiding data inside an objectnNew view: hiding anything, including:qData (implementation)qStructure (implementation)qOther object (implementation)qType (derived classes)qChange/vary (design details)qEncapsulation Correctly A

6、DTnADT = Abstract Data TypeqA concept, not an implementationqA set of (homogeneous) objects together with a set of operations on those objectsqNo mention of how the operations are implementednEncapsulation = data abstraction + typeqdata abstraction: group data and operationqType: hiding implementati

7、on, make usage correctly Why type?nA type may be viewed as a set of clothes (or a suit of armor) that protects an underlying untyped representation from arbitrary or unintended use. nIt provides a protective covering that hides the underlying representation and constrains the way objects may interac

8、t with other objects. nIn an untyped system untyped objects are naked in that the underlying representation is exposed for all to see.Encapsulate DatanIf needed, use Accessors and Mutators, Not Public Members nAccessors and Mutators is meaningful behaviorqConstraints, transformation, formatpublic vo

9、id setSpeed(double newSpeed) if (newSpeed 0) sendErrorMessage(.);newSpeed = Math.abs(newSpeed);speed = newSpeed;Encapsulate structuresnSee chapter 16 Iterator PatternReferences and Collection Data-Type !Encapsulate other objectsnCollaboration DesignqComposition; delegationEncapsulate type(subclass)n

10、LSPqpointers to superclasses or interfaces;All derived classes must be substituteablefor their base classEncapsulate Change (or vary)nIdentify the aspects of your application that may change (or vary) and separate them from what stays the same. nTake the parts that change( vary ) and encapsulate the

11、m, so that later you can alter or extend the parts that vary without affecting the parts that dont. nSee DIP and OCP LaterEncapsulate Implementation DetailnData nStructurenOther objectnTypenChange/varynPrinciple #1: Minimize The Accessibility of Classes and MembersnAbstractionqAn abstraction focuses

12、 on the outside view of an object and separates an objects behavior from its implementationnEncapsulationqClasses should not expose their internal implementation detailsMain Contents1.Encapsulation2.How to hiding change?Example of Responsibility ChangeCopyReadKeyboardWritePrintervoid Copy(ReadKeyboa

13、rd& r, WritePrinter& w) int c; while (c = r.read () != EOF) w.write (c);WriteDiskvoid Copy(ReadKeyboard& r, WritePrinter& wp, WriteDisk& wd, OutputDevice dev) int c; while(c = r.read()!= EOF) if(dev = printer) wp.write(c); else wd.write (c);How to nAbstraction is Keyq.using polymorphic dependencies

14、(calls)Example of Responsibility ChangeDiskWriter:Write(c) WriteDisk(c);CopyKeyboardReaderPrinterWriterDiskWritervoid Copy(ReadKeyboard& r, WritePrinter& w) int c; while (c = r.read () != EOF) w.write (c);Principle 10: Open/Closed Principle (OCP)Software entities should be open for extension, but cl

15、osed for modificationB. Meyer, 1988 / quoted by R. Martin, 1996Be open for extension4modules behavior can be extendedBe closed for modification4source code for the module must not be changes统计数据表明，修正bug最为频繁，但是影响很小；新增需求数量一般，但造成了绝大多数影响Modules should be written so they can be extended without requiring

16、 them to be modifiedOCPnRTTI is ugly and dangerousqRTTI = Run-Time Type InformationqIf a module tries to dynamically cast a base class pointer to several derived classes, any time you extend the inheritance hierarchy, you need to change the moduleqrecognize them by type switch or if-else-if structur

17、esRTTI is Ugly and Dangerous!/ RTTI violatingthe/open-closedprinciple and LSP class Shape class Square extends Shape void drawSquare() / draw class Circle extends Shape void drawCircle() / draw void drawShapes(List shapes) for (Shape shape : shapes) if (shapes instanceof Square) (Square) shapes).dra

18、wSquare(); else if (shape instanceof Circle) (Circle) shape).drawCircle(); /Abstraction and Polymorphism thatdoes/ notviolatetheopen-closedprinciple and LSP interface Shape void draw(); class Square implements Shape void draw() / draw implementation class Circle implements Shape void draw() / draw i

19、mplementation void drawShapes(List shapes) for (Shape shape : shapes) shape.draw(); OCP Summaryn Use abstraction to gain explicit closurenPlan your classes based on what is likely to change. qminimizes future change locationsnOCP needs DIP & LSPNo significant program can be 100% closed R.Martin, “Th

20、e Open-Closed Principle,” 1996Principle 11: Dependency Inversion Principle (DIP)I. High-level modules should not depend on low-level modules. Both should depend on abstractions.II. Abstractions should not depend on details. Details should depend on abstractionsR. Martin, 1996 DIP : separate interfac

21、e from implementation abstract nUse inheritance to avoid direct bindings to classes: Design to an interface, not an implementation!ClientInterface(abstract class)Implementation(concrete class)DIP ExampleCopyReaderWriterKeyboardReaderPrinterWriterDiskWriterclass Reader public: virtual int read()=0;cl

22、ass Writer public: virtual void write(int)=0;void Copy(Reader& r, Writer& w) int c; while(c = r.read() != EOF) w.write(c);DIP Procedural vs. OO ArchitectureProcedural ArchitectureObject-Oriented ArchitectureDIP summarynAbstract classes/interfaces:qtend to change less frequentlyq abstractions are hin

23、ge points where it is easier to extend/modifyqshouldnt have to modify classes/interfaces that represent the abstraction (OCP)nExceptionsqSome classes are very unlikely to change; ntherefore little benefit to inserting abstraction layernExample: String classqIn cases like this can use concrete class

24、directlynas in Java or C+How to deal with changeOCP states the goal; DIP states the mechanism;LSP is the insurance for DIPExample of Implementation ChangeDuckquack()swim()display()/other duck-like methodsMallardDuckdisplay() / looks like a mallardRedHeadDuckdisplay() / looks like a redhead The displ

25、ay() method is abstract, since all duck subtypes look differentdisplay() method seems will be changed by new subtypeAll ducks quack and swim. The superclass takes care of the implementation codeSingle Responsibility Principle (SRP)A class should have only one reason to changeRobert MartinDuckquack()

26、swim()display()/other duck-like methodsSRSand display()Information Hiding: Design changes!nthe most common kind of secret is a design decision that you think might change. nYou then separate each design secret by assigning it to its own class, subroutine, or other design unit.nNext you isolate (encapsulate) each secret so that if it does change, the change doesnt affect the rest of the program.34See Chapter 16 Strategy PatternDuckquack()swim()display()/other duck-like methodsMallardDuckRedHeadDuckRubberDuckDisplayBehaviordisplay()nEnd