• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Design patterns in brief
 

Design patterns in brief

on

  • 3,182 views

This presentation shows some basics of design patterns and explanation of some common used design patterns such as Singleton, Observer, Command, etc.

This presentation shows some basics of design patterns and explanation of some common used design patterns such as Singleton, Observer, Command, etc.

Statistics

Views

Total Views
3,182
Views on SlideShare
3,182
Embed Views
0

Actions

Likes
4
Downloads
73
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Initial session for Java developers @ fRun project.
  • MVC = Model + View + ControllerTan: In desktop apps(ie. Swing, WinForm), it may hire: Observer for connecting 3 layers, Command for views, Singleton or Application control (see Java Desktop Application Framework on Java.net), Strategy for models and many others (if needed).

Design patterns in brief Design patterns in brief Presentation Transcript

  • Design Patterns
    Don’t reinvent the wheel
    Hanoi - April, 2009
    Duong Trong Tan, (tandt@fpt.edu.vn)
  • What are design patterns?
    They
    are common ways of structuring programs
    typically deal with a small number of classes, but can be of any size
    provide a communication framework in which ideas can be discussed at a high level
    can specify how objects are created, how they interact, or how they are structured
  • Why design patterns?
    Reuse solutions
    Vocabulary for development
    Better software
  • Who?
    Alexandre Christopher
    ‘Gang of Four’: Erich Gamma, Richard Helm, Ralph Johnson, and John M. Vlissides
  • What?
    Gang of Four common design patterns
    Some new J2EE design patterns
  • How can design patterns be derived?
    They do use the Design Principles
    • Programming to interfaces not implementations
    • Favor composition over inheritance
    • Encapsulate what varies
    • Strive for loosely coupled between objects that interact
    • Classes should OPEN for extension and CLOSE for modification
    • Depends on abstraction, not concrete classes
    • Don't call us, we'll call you
    • A class should have only one reason to change
  • Common patterns
    Design Patterns
    Categories
    Singleton
    Builder
    Factory method
    Facade
    Decorator
    Observer
    Command
    Strategy
    Creational: How to create objects (higher level than constructors)
    Behavioral: Describing how objects interact
    Structural: Common relationships in class diagrams
    C
    S
    B
  • Singleton
    public static Counter getInstance() {
    if(uInstance == null) {
    this.uInstance = new Counter();
    return this.uInstance;
    } else {
    return this.uInstance;
    }
    }
    C
  • The purpose of Singleton
    Makes sure only one instance of an object exists within an application.
    A better solution compared to global variables
    Provide global access to the object instance.
    Example: Counter, Application Menu System, Application objects, Services, Clients
    Not as easy as you think: What about threading?
  • Factory Method
    Defines an interface for creating an object but lets subclasses decide which class to instantiate.
    Lets classes defer instantiation to subclasses
    C
  • Benefits of Factories
    We can choose what to instantiate at runtime
    We can code to an interface
    Don’t have to know exactly what kind of object we’ll get back
    We centralize code
    In order to add new types of objects, we only have to modify one place, the factory
    12
  • Builder
    C
    Separate the construction of a complex object from its representation so that the same construction process can create different representations.
  • Façade
    S
    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.
    (GoF)
  • The DBFacade Example
    Common JDBC uses:
    Open a connection to DB
    Close a connection
    Get all tables from DB
    Executes a SQL statement
    Retrieve result from a SELECT statement
    All That I Need
  • DatabaseFacade Outlook
    Client
    uses
    DatabaseFacade
    JDBC API
    Connection
    ResultSet
    ResultSetMetadata
    Statement
    DatabaseMetadata
    Driver

  • Decorator
    S
    BufferedReader in = new BufferedReader(new FileReader(“foo.in"));
  • Strategy
    B
    Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it
  • Observer
    B
    Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
    GoF
  • MVC
    What does it hire?
  • Command
    B
    “Let’s hide (encapsulate) the way we call (invoke) methods.”
  • Example: Menus
    Consider an application menu system.
    How do we de-couple our menu system from our document class?
    Composite Pattern!
    Menu contains many menu items.
    ConcreteCommand
    Client
    invoker
    We can do a lot of things (actions) with a document. Each interface might be different!
    Command Interface
    Receiver
  • AllGoFpatterns
  • J2EE patterns
    Categorized by tiers:
    • Presentation Tier
    • Business Tier
    • Integration Tier
  • Data Access Object
    Alur et al.
  • Business Objects
    Alur et al.
  • Session Façade
    Alur et al.
  • Application Service
    Alur et al.
  • References
    E. Gamma, R. Helm, R. Johnson, & J. Vlissides. Design Patterns: Elements of Object-Oriented Software. Addison-Wesley, Boston, 1995.
    D. Alur, J. Crupi and D. Malks, Core J2EE Patterns: Best Practices and Design Strategies, Second Edition, 2003