Design patterns applied example an hierarchical file system
This presentation is the property of its rightful owner.
Sponsored Links
1 / 42

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


  • 47 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Design Patterns Applied Example: An Hierarchical File System

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

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

  • 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.


/

bin/

u/

tmp/

dir

peter/

kay/

peter/

junk

junk.tex

An Hierarchical File System


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.


File

Directory

Node

Fundamental Classes


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

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.


*

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

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.


*

Node

Directory

File

Filesystem Structure


*

Node

Directory

File

Filesystem Structure: getName()


*

Node

_name

getName()

Directory

File

return _name;

Filesystem Structure: getName()


*

Node

Directory

File

Filesystem Structure: size()


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()

*


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

Purpose

CreationalStructuralBehavioral

Class Factory MethodAdapterInterpreterTemplate Method

ObjectAbstract FactoryAdapterChain of ResposibilityBuilderBridgeCommand

PrototypeCompositeIterator

SingletonDecoratorMediator

FacadeMemento

FlyweightObserver

ProxyState

Strategy

Visitor

Scope


(Siemens) Pattern Space

Architectural Patterns Design Patterns Idioms

From MudLayersInterpreter

to StructurePipes and Filters

Blackboard

DistributedBroker

SystemsPipes and Filters

Microkernel

InteractiveModel-View-Controler

SystemsPAC

AdaptableMicrokernel

SystemsReflections

CreationAbstract FactorySingleton

PrototypeFactory Method

Builder


Architectural Patterns Design Patterns Idioms

StructuralWhole Part

Decomposition= Composite

OrganisationMaster Slave

of WorkChain of Resp-

onsibility

Command

Mediator

Access Proxy

ControlFacade

Iterator

ServiceBridgeTemplate Method

VerificationStrategy

State

ServiceDecorator

ExtensionVisitor


Architectural Patterns Design Patterns Idioms

ManagementCommand Pro-

cessor

View Handler

Memento

AdaptionAdapter

CommunicationPublisher Subscriber

= Observer

Forwarder Receiver

Client Dispatcher Server

RessourceFlyweightCounted Pointer

Handling


Aspects that patterns let you vary

Abstract Factoryfamilies of product objects

Builderhow a composite object gets created

Factory Methodsubclass of object that is instantiated

Prototypeclass of object that is instantiated

Singletonthe sole instance of a class

Adapterinterface to an object

Bridgeimplementation of an object

Compositestructure and composition of an object

Decoratorresponsibility of an object

without subclassing

Facadeinterface to a subsystem

Creational

Structural


Flyweightstorage cost of objects

Proxyhow an object is accessed; its location

Chain of Responsibilityobject that can fulfill a request

Commandwhen and how a request is fulfilled

Interpretergrammer and interpretation of a language

Iteratorhow an aggregate´s element is accessed

Mediatorhow an which objects interact with each o.

Mementowhat private information is stored outside

Observerhow dependent objects stay up to date

Statestates of an object

Strategyan algorithm

Template Methodsteps of an algorithm

Visitoroperations that can be applied to object()s

without changing their class(es)

Behavioral


Client

Subject

Proxy

RealSubject

request()

request()

request()

realSubject

realSubject->request()

Proxy: Structure


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'

*


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 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

  • 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.


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)


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


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 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


AbstractClass

ConcreteClass

templateMethod()

primitiveOperation1()

primitiveOperation2()

primitiveOperation1()

primitiveOperation2()

...

primitiveOperation1();

...

primitiveOperation2();

...

Template Method: Structure


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 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


NodeVisitor

CatVisitor

Summary: File System Design

Node

Link

File

Directory

User

Grouping

Group


Composite

NodeVisitor

Component

Node

Node

CatVisitor

Link

Link

File

File

Directory

Directory

Composite

Leaf

Leaf

User

Grouping

Group

Summary: File System Design


Proxy

NodeVisitor

Subject

Node

Node

CatVisitor

Link

Link

File

File

Directory

Directory

RealSubject

Proxy

RealSubject

User

Grouping

Group

Summary: File System Design


TemplateMethod

NodeVisitor

AbstractClass

Node

Node

CatVisitor

Link

Link

File

File

Directory

Directory

ConcreteClass

ConcreteClass

ConcreteClass

User

Grouping

Group

Summary: File System Design


NodeVisitor

NodeVisitor

Node

CatVisitor

CatVisitor

User

Grouping

Group

Summary: File System Design

Visitor

Visitor

ConcreteVisitor

Element

Node

ConcreteElement

ConcreteElement

Link

File

Directory

ConcreteElement


NodeVisitor

Node

CatVisitor

Link

File

Directory

User

User

Grouping

Grouping

Group

Group

Summary: File System Design

Mediator

ConcreteColleague

ConcreteColleague

ConcreteMediator


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

  • A Common Design Vocabulary

  • A Documentation and Learning Aid

  • An Adjunct to Existing Methods

  • A Target for Refactoring


  • Login