Design patterns applied example an hierarchical file system
Download
1 / 42

Design Patterns Applied Example: An Hierarchical File System - PowerPoint PPT Presentation


  • 65 Views
  • Uploaded on

Design Patterns Applied Example: An Hierarchical File System. Design Patterns Applied. Example: An Hierarchical File System Tree Structure  Composite Patterns Overview Symbolic Links  Proxy Extending Functionality  Visitor Single User Protection  Template Method

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Design Patterns Applied Example: An Hierarchical File System' - melinda-rowe


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Design patterns applied example an hierarchical file system

Design Patterns Applied Example: An Hierarchical File System


Design patterns applied
Design Patterns Applied

Example: An Hierarchical File System

Tree Structure  Composite

Patterns Overview

Symbolic Links  Proxy

Extending Functionality  Visitor

Single User Protection  Template Method

Multi User Protection  Singleton

Users and Groups  Mediator

Conclusion


Example an hierarchical file system
Example: An Hierarchical File System

  • Case Study: Designing

    • an object-oriented and extensible programming model for the application writers use,

    • i.e. the application programming interface of an hierarchical file system.

    • We won‘t concern ouerselves with low-level implementation issues such as I/O buffering and disk-sector management.

    • Our clients are for example user-level commands dealing with the file system.


An hierarchical file system

/

bin/

u/

tmp/

dir

peter/

kay/

peter/

junk

junk.tex

An Hierarchical File System


Requirements
Requirements

  • The file system should handle file structures of arbitary size and complexity.

  • It shouldn´t put arbitary limits on how wide or deep the file structure can be.

  • The representation for the file structure should be easy to deal with and to extend.

  • One should be able to treat directories and files the same when requesting for example their names.

  • It should be possible to accomodate new kinds of files (symbolic links, for example) without reimplementing half the system.


Fundamental classes

File

Directory

Node

Fundamental Classes


Gof pattern templates

Name and Classification

Intent

What particular design issue or problem does the pattern address?

Also Known As

Motivation

A scenario that illustrates a design problem and how the class and object structures in the pattern solve the problem.

Applicability

What are examples of poor design that it can address?

Structure

Participants

Collaborations

Consequences

What are the trade-offs and results of using the pattern?

Implementation

What pitfalls, hints, ... should you be aware of when implementing it.

Sample Code

Known Uses

Related Patterns

GOF Pattern Templates


Composite intent and applicability
Composite: Intent and Applicability

Intent

  • Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects nd compositions of objects uniformly.

    Applicability

  • Use the Composite pattern when

    • you want to represent part-whole hierarchies of objects.

    • you want clients to be able to ignore the difference between compositions of objects and individual objects. Cliens will treat all objects in the composite structure uniformly.


Composite structure

*

Client

Component

Composite

Leaf

operation()

add(Component)

remove(Component)

getChild(int)

operation()

operation()

add(Component)

remove(Component)

getChild(int)

children

forall g in children

g.operation();

Composite: Structure


Composite participants
Composite: Participants

Component

  • declares the interface for objects in the composition.

  • implements default behavior for the interface, as appropriate.

  • declares an interface for accessing and managing its childs.

    Leaf

  • represents leaf objects in the composition.

  • defines behavior for primitive objects in the composition.

    Composite

  • defines behavior for components having children.

  • stores child components.

  • implements child-related behavior.


Filesystem structure

*

Node

Directory

File

Filesystem Structure


Filesystem structure getname

*

Node

Directory

File

Filesystem Structure: getName()


Filesystem structure getname1

*

Node

_name

getName()

Directory

File

return _name;

Filesystem Structure: getName()


Filesystem structure size

*

Node

Directory

File

Filesystem Structure: size()


Filesystem structure size1

Node

size()

Directory

File

size()

size()

long Directory::size(){

long total = o;

Node* child;

for (int i=0; child=getChild(i); ++i) {total=+=child->size();}

return total;

}

Filesystem Structure: size()

*


Filesystem structure1

Node()

File()

Directory()

getName()

streamIn(istream)

streamOut(ostream)

getChild(int)

adopt(Node)

orphan(Node)

size()

streamIn(istream)

streamOut(ostream)

size()

streamIn(istream)

streamOut(ostream)

getChild(int)

adopt(Node)

orphan(Node)

size()

cerr << getName()

<< " is not a directory."

<< endl;

cerr << child ->getName()

<< " is not a directory."

<< endl;

Filesystem Structure

*


Gof design pattern space
(GOF) Design Pattern Space

Purpose

CreationalStructuralBehavioral

Class Factory MethodAdapter Interpreter Template Method

Object Abstract FactoryAdapterChain of ResposibilityBuilderBridgeCommand

PrototypeCompositeIterator

SingletonDecoratorMediator

FacadeMemento

FlyweightObserver

ProxyState

Strategy

Visitor

Scope


Siemens pattern space
(Siemens) Pattern Space

Architectural Patterns Design Patterns Idioms

From Mud Layers Interpreter

to Structure Pipes and Filters

Blackboard

Distributed Broker

Systems Pipes and Filters

Microkernel

Interactive Model-View-Controler

Systems PAC

Adaptable Microkernel

Systems Reflections

Creation Abstract Factory Singleton

Prototype Factory Method

Builder


Architectural Patterns Design Patterns Idioms

Structural Whole Part

Decomposition = Composite

Organisation Master Slave

of Work Chain of Resp-

onsibility

Command

Mediator

Access Proxy

Control Facade

Iterator

Service Bridge Template Method

Verification Strategy

State

Service Decorator

Extension Visitor


Architectural Patterns Design Patterns Idioms

Management Command Pro-

cessor

View Handler

Memento

Adaption Adapter

Communication Publisher Subscriber

= Observer

Forwarder Receiver

Client Dispatcher Server

Ressource Flyweight Counted Pointer

Handling


Aspects that patterns let you vary
Aspects that patterns let you vary

Abstract Factory families of product objects

Builder how a composite object gets created

Factory Method subclass of object that is instantiated

Prototype class of object that is instantiated

Singleton the sole instance of a class

Adapter interface to an object

Bridge implementation of an object

Composite structure and composition of an object

Decorator responsibility of an object

without subclassing

Facade interface to a subsystem

Creational

Structural


Flyweight storage cost of objects

Proxy how an object is accessed; its location

Chain of Responsibility object that can fulfill a request

Command when and how a request is fulfilled

Interpreter grammer and interpretation of a language

Iterator how an aggregate´s element is accessed

Mediator how an which objects interact with each o.

Memento what private information is stored outside

Observer how dependent objects stay up to date

State states of an object

Strategy an algorithm

Template Method steps of an algorithm

Visitor operations that can be applied to object()s

without changing their class(es)

Behavioral


Proxy structure

Client

Subject

Proxy

RealSubject

request()

request()

request()

realSubject

realSubject->request()

Proxy: Structure


Filesystem structure with symbolic links

Node()

File()

Directory()

Link()

getName()

streamIn(istream)

streamOut(ostream)

getChild(int)

adopt(Node)

orphan(Node)

size()

streamIn(istream)

streamOut(ostream)

size()

streamIn(istream)

streamOut(ostream)

getChild(int)

adopt(Node)

orphan(Node)

size()

streamIn(istream)

streamOut(ostream)

getChild(int)

getSubject()

subject

return subject->getChild(n);

Filesystem Structure with 'symbolic links'

*


Extensibility

void Client:: cat(Node* node) {

Link* l;

if (dynamic_cast<File*>(node)) {

node->streamOut(cout);

} else if (dynamic_cast<Directory*>(node)) {

cerr << “Can`t cat a directory.” << endl;

} else if (l = dynamic_cast<Link*>(node)) {

cat(l->getSubject());

}

}

Extensibility

  • The filesystem should provide a complete but minimal set of functionality.

    Discussion:

    wc

    cat

    ...


Design patterns applied1
Design Patterns Applied

Example: An Hierarchical File System

Tree Structure  Composite

Patterns Overview

Symbolic Links  Proxy

Extending Functionality  Visitor

Single User Protection  Template Method

Multi User Protection  Singleton

User and Groups  Mediator

Conclusion


Visitor intent
Visitor: Intent

  • Represent an operation to be performed on the elements of an object structure.

  • Visitor lets you define a new operation without changing the classes of the elements on which it operates.


Visitor structure

ConcreteVisitor1

ConcreteElementA

ConcreteElementB

visitElementA(ConcreteElementA)

visitElementB(ConcreteElementB)

accept(Visitor v)

operationA()

accept(Visitor v)

operationB()

ConcreteVisitor2

Element

Visitor

visitElementA(ConcreteElementA)

visitElementB(ConcreteElementB)

visitElementA(ConcreteElementA)

visitElementB(ConcreteElementB)

accept(Visitor)

Visitor: Structure

Client

*

ObjectStructure

v->visitElementB(this)


Extensible filesystem structure catvisitor

Node()

File()

Directory()

NodeVisitor()

CatVisitor()

*

visitFile(File*)

visitDirectory(Directory*)

visitLink(Link*)

visitFile(File*)

visitDirectory(Directory*)

visitLink(Link*)

accept(NodeVisitor&)

accept(NodeVisitor&)

accept(NodeVisitor&)

v.visitDirectory(this)

v.visitFile(this)

f->stream(cout);

cerr<<“Can`t cat a directory.”<<endl;

l->getSubject()->accept(*this);

Extensible Filesystem Structure - CatVisitor


Extensible filesystem structure spvisitor

Node()

File()

Directory()

SuffixPrintVisitor()

NodeVisitor()

CatVisitor()

*

accept(NodeVisitor&)

accept(NodeVisitor&)

accept(NodeVisitor&)

visitFile(File*)

visitDirectory(Directory*)

visitLink(Link*)

visitFile(File*)

visitDirectory(Directory*)

visitLink(Link*)

visitFile(File*)

visitDirectory(Directory*)

visitLink(Link*)

Extensible Filesystem Structure - SPVisitor


Design patterns applied2
Design Patterns Applied

Example: An Hierarchical File System

Tree Structure  Composite

Patterns Overview

Symbolic Links  Proxy

Extending Functionality  Visitor

Single User Protection  Template Method

Multi User Protection  Singleton

User and Groups  Mediator

Conclusion


Template method structure

AbstractClass

ConcreteClass

templateMethod()

primitiveOperation1()

primitiveOperation2()

primitiveOperation1()

primitiveOperation2()

...

primitiveOperation1();

...

primitiveOperation2();

...

Template Method: Structure


File system structure read protection

Node

File

streamOut(ostream)

setProtection(protection)

getProtection()

#doStreamOut(ostream)

#doStreamOut(ostream)

void Node::streamOut (ostream& out) {

if (isReadable()) {

doStreamOut(out);

} else {

doWarning(unreadableWarning);

}

}

File System Structure: Read Protection


Design patterns applied3
Design Patterns Applied

Example: An Hierarchical File System

Tree Structure  Composite

Patterns Overview

Symbolic Links  Proxy

Extending Functionality  Visitor

Single User Protection  Template Method

Multi User Protection  Singleton

User and Groups  Mediator

Conclusion


Summary file system design

NodeVisitor

CatVisitor

Summary: File System Design

Node

Link

File

Directory

User

Grouping

Group


Summary file system design1

Composite

NodeVisitor

Component

Node

Node

CatVisitor

Link

Link

File

File

Directory

Directory

Composite

Leaf

Leaf

User

Grouping

Group

Summary: File System Design


Summary file system design2

Proxy

NodeVisitor

Subject

Node

Node

CatVisitor

Link

Link

File

File

Directory

Directory

RealSubject

Proxy

RealSubject

User

Grouping

Group

Summary: File System Design


Summary file system design3

TemplateMethod

NodeVisitor

AbstractClass

Node

Node

CatVisitor

Link

Link

File

File

Directory

Directory

ConcreteClass

ConcreteClass

ConcreteClass

User

Grouping

Group

Summary: File System Design


Summary file system design4

NodeVisitor

NodeVisitor

Node

CatVisitor

CatVisitor

User

Grouping

Group

Summary: File System Design

Visitor

Visitor

ConcreteVisitor

Element

Node

ConcreteElement

ConcreteElement

Link

File

Directory

ConcreteElement


Summary file system design5

NodeVisitor

Node

CatVisitor

Link

File

Directory

User

User

Grouping

Grouping

Group

Group

Summary: File System Design

Mediator

ConcreteColleague

ConcreteColleague

ConcreteMediator


Summary file system design6

NodeVisitor

Node

CatVisitor

Link

File

Directory

User

User

Grouping

Grouping

Group

Summary: File System Design

Singleton

Singleton(variant)

Singleton


What to expect from design patterns
What to Expect from Design Patterns

  • A Common Design Vocabulary

  • A Documentation and Learning Aid

  • An Adjunct to Existing Methods

  • A Target for Refactoring


ad