Design Patterns Applied Example: An Hierarchical File System

1. Design Patterns Applied Example: An Hierarchical File System

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

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

4. / bin/ u/ tmp/ dir peter/ kay/ peter/ junk junk.tex An Hierarchical File System

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

6. File Directory Node Fundamental Classes

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

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

9. * 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

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

11. * Node Directory File Filesystem Structure

12. * Node Directory File Filesystem Structure: getName()

13. * Node _name getName() Directory File return _name; Filesystem Structure: getName()

14. * Node Directory File Filesystem Structure: size()

15. 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() *

16. 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 *

17. (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

18. (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

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

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

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

22.  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

23. Client Subject Proxy RealSubject request() request() request() realSubject realSubject->request() Proxy: Structure

24. 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' *

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

26. 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 

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

28. 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)

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

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

31. 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 

32. AbstractClass ConcreteClass templateMethod() primitiveOperation1() primitiveOperation2() primitiveOperation1() primitiveOperation2() ... primitiveOperation1(); ... primitiveOperation2(); ... Template Method: Structure

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

34. 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 

35. NodeVisitor CatVisitor Summary: File System Design Node Link File Directory User Grouping Group

36. Composite NodeVisitor Component Node Node CatVisitor Link Link File File Directory Directory Composite Leaf Leaf User Grouping Group Summary: File System Design

37. Proxy NodeVisitor Subject Node Node CatVisitor Link Link File File Directory Directory RealSubject Proxy RealSubject User Grouping Group Summary: File System Design

38. TemplateMethod NodeVisitor AbstractClass Node Node CatVisitor Link Link File File Directory Directory ConcreteClass ConcreteClass ConcreteClass User Grouping Group Summary: File System Design

39. NodeVisitor NodeVisitor Node CatVisitor CatVisitor User Grouping Group Summary: File System Design Visitor Visitor ConcreteVisitor Element Node ConcreteElement ConcreteElement Link File Directory ConcreteElement

40. NodeVisitor Node CatVisitor Link File Directory User User Grouping Grouping Group Group Summary: File System Design Mediator ConcreteColleague ConcreteColleague ConcreteMediator

41. NodeVisitor Node CatVisitor Link File Directory User User Grouping Grouping Group Summary: File System Design Singleton Singleton(variant) Singleton

42. What to Expect from Design Patterns • A Common Design Vocabulary • A Documentation and Learning Aid • An Adjunct to Existing Methods • A Target for Refactoring