Second Midterm Review

Transcription

1 Second Midterm Review Comp-303 : Programming Techniques Lecture 24 Alexandre Denault Computer Science McGill University Winter 2004 April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 1

2 Announcements Don t forget the midterm next Thursday in Leacock 26. Don t forget to hand-in the CD with your project next Thursday. Don t forget the project interview on April 15th an 16th. Two teams still haven t signed up. April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 2

3 Last lecture... The JCP controls the evolution of the Java Specification. Java 1.5 introduces some interesting new improvements, most of them focused at making life easier for the programmer. April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 3

4 Second Midterm This exam is only composed of short-answer questions. There are 20 questions. Seven of them are related to material found in Lecture You don t need to read/write code. You don t need to draw anything. April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 4

5 Lecture 14: Testing and Debugging Validation Verification Testing ( Black-box / Glass-box ) Debugging (strategies) Defensive programming Boundary Conditions Path-Completeness Regression Testing Unit Testing Test Drivers / Stubs April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 5

6 Lecture 15: Requirement Analysis Software Life Cycle ( Waterfall, Spiral, Prototype ) Goals Existing Systems Errors (Users, System, Hardware ) Performance Requirements Constraints April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 6

7 Lecture 16: Between Design and Imp. Purpose / Goal of Design Evaluating a Design Design Reviews Coherence Module communication / Dependencies Development process / strategies April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 7

8 Lecture 17: Design Patterns, Singleton Origins of Design Patterns What are patterns? The Design Pattern Bible April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 8

9 Lecture 17: Design Patterns, Singleton Pattern Name : Singleton Classification : Creational Intent : Ensure a class only has one instance, and provide a global point of access to it. April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 9

10 Lecture 17: Design Patterns, Singleton The Singleton pattern should be used when there must be exactly one instance of a class and it must be accessible to clients from a well-known access point.... the sole instance should extensible by subclassing, and clients should be able to use an extended instance without modifying there code. April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 10

11 Lecture 17: Design Patterns, Singleton Singleton static uniqueinstance singletondata static Instance() SingletonOperation() GetSingletonData() return uniqueinstance April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 11

12 Lecture 18: Fact. Methods and Abstract Fact. Pattern Name : Abstract Factory Classification : Creational Also known as : Kit Intent : Provide an interface for creating families of related or dependent objects without specifying their concrete classes. April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 12

13 Lecture 18: Fact. Methods and Abstract Fact. The Abstract Factory pattern should be used when a system should be independent of how its products are created, composed and represented.... a system should be configured with one of multiple families of products.... a family of related product objects is designed to be used together, and you need to enforce this constant.... you want to provide a class library of products, and you want to reveal just their interfaces, not their implementations. April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 13

14 Lecture 18: Fact. Methods and Abstract Fact. AbstractFactory Application +CreateProductA() +CreateProductB() AbstractProductA ConcreteFactory1 ConcreteFactory2 ProductA2 ProductA1 +CreateProductA() +CreateProductB() +CreateProductA() +CreateProductB() AbstractProductB ProductB2 ProductB1 April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 14

15 Lecture 18: Fact. Methods and Abstract Fact. Pattern Name : Factory Method Classification : Creational Also known as : Virtual Constructor Intent : Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 15

16 Lecture 18: Fact. Methods and Abstract Fact. The Factory Method pattern should be used when a class can t anticipate the class of objects it must create.... a class wants its subclasses to specify the objects it creates.... classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate. April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 16

17 Lecture 18: Fact. Methods and Abstract Fact. Product Creator +FactoryMethod() +AnOperation()... product = FactoryMethod();... ConcreteProduct ConcreteCreator +FactoryMethod() return new ConcreteProduct April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 17

18 Lecture 19: Facade and Adapter Pattern Name : Facade Classification : Structural Intent : Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 18

19 Lecture 19: Facade and Adapter The Facade pattern should be used when you want to provide a simple interface to a complex subsystem.... there are many dependencies between clients and the implementation classes of an abstraction.... you want to layer your subsystems. April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 19

20 Lecture 19: Facade and Adapter DatabaseFacade Subsystem A Subsystem D Subsystem B Subsystem C April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 20

21 Lecture 19: Facade and Adapter Pattern Name : Adapter Classification : Structural Also known as : Wrapper Intent : Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn t otherwise because of incompatible interfaces. April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 21

22 Lecture 19: Facade and Adapter The Adapter pattern should be used when you want to use an existing class, and its interface does not match the one you need.... you want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don t necessarily have compatible interfaces.... you need to use several existing subclasses, but it s impractical to adapt their interface by subclassing every one. April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 22

23 Lecture 19: Facade and Adapter Client Target request() Adaptee... Adapter refadaptee: Adaptee request() specialrequest() refadaptee.specialrequest() April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 23

24 Lecture 20: Flyweight Pattern Name : Flyweight Classification : Structural Intent : Use sharing to support large numbers of fine-grained objects efficiently. April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 24

25 Lecture 20: Flyweight The Flyweight pattern s effectiveness depends heavily on how and where it s used. Flyweight should only be used when all the following are true: An application uses a large number of objects. Storage costs are high because of the sheer quantity of objects. Most object state can be made extrinsic. Objects can be replaced by few shared objects once the extrinsic state is removed. The application doesn t depend on object identity. April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 25

26 Lecture 20: Flyweight FlyweightFactory GetFlyweight(Key) Flyweight Operation(ExtrinsicState) if(flyweight(key) exists { return existing flyweight } else { create new flyweight } IntrinsicState ConcreteFlyweight Operation(ExtrinsicState) IntrinsicState UnSharedFlyweight Operation(ExtrinsicState) Client April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 26

27 Lecture 21: Chain of Responsibility Pattern Name : Chain of Responsibility Classification : Behavioral Intent : Avoid coupling the sender of a request to its receiver by giving more that one object the chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 27

28 Lecture 21: Chain of Responsibility Use Chain of Responsibility when more than one object may handle a request, and the handler isn t known ahead of time.... you want to issue a request to one of several objects without specifying the receiver explicitly.... the set of objects that can handle a request should be specified dynamically. April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 28

29 Lecture 21: Chain of Responsibility Client Handler successor: Handler HandleRequest() ConcreteHandler1 successor: Handler HandleRequest() ConcreteHandler2 successor: Handler HandleRequest() April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 29

30 Lecture 22: Command Pattern Name : Command Classification : Behavioral Also Known As : Action, Transaction Intent : Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 30

31 Lecture 22: Command Use Command when you want to parameterize objects by an action to perform. In procedural languages, this would be called a callback function.... specify, queue and execute requests at different times.... support undo/redo.... support logging of changes so that they can be reapplied in case of a system crash (transaction).... structure a system around high-level operations built on primitives operations. April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 31

32 Lecture 22: Command Client Invoker Command Execute() Receiver Action() state ConcreteCommand Execute() receiver->action(); April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 32

33 Lecture 23: Java 1.5 J2ME, J2SE. J2EE Java Community Process Java Specification Requests Java 1.5 Enumerated types Metadata / Autoboxing of primitive types Enhanced looping Improved diagnostics and for the first time Use of generics April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 33

34 Tools of the course Java in our lives Nokia 5100 Thinkfree Office Air Conditioners Shell HomeGenie Editors and Generators jedit Eclipse JCreator Dia (with Dia2Code) Source Manipulation / Control CVS JavaDoc April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 34

35 Compilers & VM Jikes Java 2 SE 1.5 SableVM Compiler & VM Tools Jar files Ant ProGuard SableCC Debugging and Information Google NewsGroups Jdb JProfiler Tools of the course April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 35

36 Course Summary Being a good programmer has nothing to do with speed or hacking skills. Programmers should aim for modularity, flexibility and simpleness. I hope, when leaving my course, you will have at least learned: The importance of working in a team. The importance of proper modularity. Java is not that bad as a language. A few new ways to improve your coding skills. April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 36

37 References These slides are inspired (i.e. copied) from these three books. Design Patterns, Elements of Reusable Object-Oriented Software; Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides; Addison Wesley; 1995 Java Design Patterns, a Tutorial; James W. Cooper Addison Wesly; 2000 Design Patterns Explained, A new Perspective on Object Oriented Design; Alan Shalloway, James R. Trott; Addison Wesley; 2002 April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 37

38 References (cont.) J2SE 1.5 in a Nutshell Java 1.5 SDK Documentation Sun Lights Up Java 1.5 Beta Java Community Process April 5, 2004 Lecture 24 Comp 303 : Second Midterm Review Page 38