1 / 16

Multiuser Protection and the Mediator Pattern

Multiuser Protection and the Mediator Pattern. CSE432 02/22/2006 Matt Brenneke. Multiuser Protection. Follow Unix design, user and other Users must have a login name Basic authentication, user must provide login name and password. User Object Restrictions.

whatch
Download Presentation

Multiuser Protection and the Mediator Pattern

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Multiuser Protection and the Mediator Pattern CSE432 02/22/2006 Matt Brenneke

  2. Multiuser Protection • Follow Unix design, user and other • Users must have a login name • Basic authentication, user must provide login name and password

  3. User Object Restrictions • Clients can’t create User objects at will • User object must always have a valid login name • Client can’t instantiate a user w/o name and password

  4. Creation • Abstract Factory? No, Families of Objects • Builder? No, different representation • Factory Method? No, similar to Abstract Fact. • Prototype? No, What, not How • Singleton? Bingo!

  5. Singleton - modified • Authentication • Call Intantiate() logIn(), and add user and password parameters. • Can return 0 if user or password is invalid • Client can’t change logIn() by subclassing User • Multiple User objects • Keeps a hash of User objects • Only one User object per username

  6. Reading a file • Before • streamOut(ostream&); • Now • streamOut(ostream&, User*);

  7. Common case • Give the user parameter a default value • void streamOut(ostream&, const User* = 0); • Add setUser and getUser functions to the User class • static const User* User::getUser(); • static void User::setUser(const User*);

  8. streamOut() changes • Check for User* == 0 • Call User::getUser() if true • isReadable() -> isReadableBy(user) • isReadableBy checks User->getLoginName against the Node’s owner.

  9. Groups? • Groups have zero or more users. • A user can be a member of zero or more groups.

  10. Group Object Representation • Composite? No • Groups aren’t recursive • A user might belong to several groups • Don’t want to treat groups and users the same • Mediator! • Relationship between groups and nodes is complex and variable • Needs loose coupling

  11. Mediator Overview • Intent • Encapsulate how a set of objects interact • Promote loose coupling • Allows you to vary interaction independently

  12. Mediator Participants • Mediator • Interface for communicating with Colleagues • ConcreteMediator (optional) • Implements coordination between Colleagues • Knows and maintains its Colleagues • Colleague classes • Knows its mediator class • Communicates with Mediator only

  13. Mediator Consequences • Limits Subclassing • Decouples Colleagues • Simplifies object protocols • Abstracts how objects cooperate • Centralizes control • May become monolithic itself

  14. Applied to Groups Users Groups Mediator Grouping

  15. Group Class members • static getGrouping() • static setGrouping(Grouping*, User*); • register(User*,Group*,User*); • unregister(User*, Group*, User*); • getGroup(string, index); • getUser(Group, index);

  16. Wrapping Up Chapter 2 • Composite provides structure • Proxy provides symlinks • Visitor allows new, type specific functionality • Template Method provided basic protection • Singleton and Mediator combine to allow full Multi-user protection

More Related