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


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


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

ObjectAbstract FactoryAdapterChain of ResposibilityBuilderBridgeCommand

PrototypeCompositeIterator

SingletonDecoratorMediator

FacadeMemento

FlyweightObserver

ProxyState

Strategy

Visitor

Scope


Siemens pattern space

(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


Design patterns applied example an hierarchical file system

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


Design patterns applied example an hierarchical file system

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

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


Design patterns applied example an hierarchical file system

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


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


  • Login