DOC PREVIEW
Yale CPSC 427 - Object-Oriented Programming
School name Yale University
Pages 20

This preview shows page 1-2-19-20 out of 20 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

OutlineDesign PatternsOutline Design PatternsCPSC 427a: Object-Oriented ProgrammingMichael J. FischerLecture 22aNovember 17, 2011CPSC 427a, Lecture 22a 1/20Outline Design PatternsDesign PatternsCPSC 427a, Lecture 22a 2/20Outline Design PatternsDesign PatternsCPSC 427a, Lecture 22a 3/20Outline Design PatternsGeneral OO principles1. Encapsulation Data members should be private. Publicaccessing functions should be defined only when absolutelynecessary. This minimizes the ways in which one class candepend on the representation of another.2. Narrow interface Keep the interface (set of public functions)as simple as possible; include only those functions that are ofdirect interest to client classes. Utility functions that are usedonly to implement the interface should be kept private. Thisminimizes the chance for information to leak out of the classor for a function to be used inappropriately.3. Delegation A class that is called upon to perform a taskoften delegates that task (or part of it) to one of its memberswho is an expert.CPSC 427a, Lecture 22a 4/20Outline Design PatternsWhat is a design pattern?A pattern has four essential elements.11. A pattern name.2. The problem, which describes when to apply the pattern.3. The solution, which describes the elements, relations, andresponsibilities.4. The consequences, which are the results and tradeoffs.1Erich Gamma et al., Design Patterns, Addison-Wesley, 1995.)CPSC 427a, Lecture 22a 5/20Outline Design PatternsAdaptor patternSometimes a toolkit class is not reusable because its interface doesnot match the domain-specific interface an application requires.Solution: Define an adapter class that can add, subtract, oroverride functionality, where necessary.CPSC 427a, Lecture 22a 6/20Outline Design PatternsAdaptor diagramThere are two ways to do this; on the left is a class adapter, on theright an object adapter.TargetClassAdaptorrequest()request()AdapteerightAction_wrongName()ClassAdaptor::request() { rightAction_wrongName();} ClientObjectAdaptor::request() { a->rightAction_wrongName(); } TargetObjectAdaptorAdapteerightAction_wrongName()request()request()ClientAdaptee* aCPSC 427a, Lecture 22a 7/20Outline Design PatternsIndirectionThis pattern is used to decouple the application from theimplementation where an implementation depends on the interfaceof some low-level device.Goal is to make the application stable, even if the device changes.AirlineSeatif_seat()reserve_seat()free_seat()...Modemdial();receive();send()...System API calls: open_port(int); dial(phonenumber);Modem::dial(phonenumber){ :: open_port(1); :: dial(2039821234);}calls callsCPSC 427a, Lecture 22a 8/20Outline Design PatternsProxy patternThis pattern is like Indirection, and is used when direct access to acomponent is not desired or possible.Solution: Provide a placeholder that represents the inaccessiblecomponent to control access to it and interact with it. Theplaceholder is a local software class. Give it responsibility forcommunicating with the real component.Special cases: Device proxy, remote proxy. In Remote Proxy, thesystem must communicate with an object in another address space.CPSC 427a, Lecture 22a 9/20Outline Design PatternsPolymorphism patternIn an application where the abstraction has more than oneimplementation, define an abstract base class and one or moresubclasses.Let the subclasses implement the abstract operations.This decouples the implementation from the abstraction and allowsmultiple implementations to be introduced, as needed.CPSC 427a, Lecture 22a 10/20Outline Design PatternsPolymorphism diagramUndergradStudentregister( course ) { ... }Studentregister( course ) =0Alumnusregister( course ) { ... }register( course ) { ... }GradStudentCPSC 427a, Lecture 22a 11/20Outline Design PatternsControllerA controller class takes responsibility for handling a system event.The controller should coordinate the work that needs to be doneand keep track of the state of the interaction. It should delegateall other work to other classes.CPSC 427a, Lecture 22a 12/20Outline Design PatternsThree kinds of controllersA controller class represents one of the following choices:IThe overall application, business, or organization (facadecontroller).ISomething in the real world that is active that might beinvolved in the task (role controller).Example: A menu handler.IAn artificial handler of all system events involved in a givenuse case (use-case controller).Example: A retail system might have separate controllers forBuyItem and ReturnItem.Choose among these according to the number of events to behandled, cohesion and coupling, and to decide how manycontrollers there should be.CPSC 427a, Lecture 22a 13/20Outline Design PatternsBridge patternBridge generalizes the Indirection pattern.It is used when both the application class and the implementationclass are (or might be) polymorphic.Bridge decouples the application from the polymorphicimplementation, greatly reducing the amount of code that must bewritten, and making the application much easier to port todifferent implementation environments.CPSC 427a, Lecture 22a 14/20Outline Design PatternsBridge diagramIn the diagram below, we show that there might be several kinds ofwindows, and the application might be implemented on twooperating systems. The bridge provides a uniform pattern for doingthe job.ImageWindowWindowDialogWindowdraw_box()draw_text()draw_rectangle()draw_border()WIP : WindowImp*XWindowImp WindowNTImpWindowImplementationimp_draw_text() imp_draw_rectangle()=0=0imp_draw_text();imp_draw_rectangle();imp_draw_text();imp_draw_rectangle();DialogWindow::draw_box() { draw_rectangle(); draw_text();} ImageWindow::draw_border() { draw_rectangle(); } Window::draw_text() { WIP->draw_text(); } CPSC 427a, Lecture 22a 15/20Outline Design PatternsSubject-Observer or Publish-Subscribe: problemProblem: Your application program has many classes and manyobjects of some of those classes. You need to maintain consistencyamong the objects so that when the state of one changes, itsdependents are automatically notified. You do not want tomaintain this consistency by using tight coupling among theclasses.Example: An OO spreadsheet application contains a data object,several presentation “views” of the data, and some graphs basedon the data. These are separate objects. But when the datachanges, the other objects should automatically change.CPSC 427a, Lecture 22a 16/20Outline Design PatternsSubject-Observer or


View Full Document

Yale CPSC 427 - Object-Oriented Programming

Download Object-Oriented Programming
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Object-Oriented Programming and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Object-Oriented Programming 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?