Mongo Inversion of Control More Design Patterns CSC301 WINTER 2020 MONGO. MANAGING OBJECTS. IOC. Ilir Dema University of Toronto Mar 2-3, 2021 Mongo Inversion of Control More Design Patterns OVERVIEW 1 MONGO 2 INVERSION OF CONTROL 3 MORE DESIGN PATTERNS Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns Mongo Inversion of Control More Design Patterns DESIGNING REUSABLE CLASSES Mongo Inversion of Control More Design Patterns THE ORIGINS OF INVERSION OF CONTROL FRAMEWORKS • An object-oriented abstract design, also called a framework, consists of an abstract class for each major component. • Frameworks can be built on top of other frameworks by sharing abstract classes. • The framework often plays the role of the main program in coordinating and sequencing application activity. • This inversion of control gives frameworks the power to serve as extensible skeletons. • The methods supplied by the user tailor the generic algorithms defined in the framework for a particular application. – Johnson, Foote. Designing reusable classes. Mongo Inversion of Control More Design Patterns WHERE IS THE DIFFERENCE? Mongo Inversion of Control More Design Patterns WHERE IS THE DIFFERENCE? Mongo Inversion of Control More Design Patterns WHERE IS THE DIFFERENCE? INVERSION OF CONTROL • In the text-based EnterData the user decides when System.out.println(name); is called. • In the GUI example, I hand control over to the windowing system. • It then decides when to call System.out.println(...);, based on the bindings I made when creating the form. • This phenomenon is Inversion of Control (also known as the Hollywood Principle - "Don’t call us, we’ll call you"). – Martin Fowler. Inversion of Control. Mongo Inversion of Control More Design Patterns OTHER EXAMPLES JUNIT • In JUnit, the framework code calls setUp and tearDown methods for you to create and clean up your text fixture. It does the calling, your code reacts - so again control is inverted. Mongo Inversion of Control More Design Patterns IOC CONTAINERS Mongo Inversion of Control More Design Patterns IMPLEMENTING IOC CONTAINERS • Dependency Injection: The control on how dependencies are acquired by client classes no longer resides in these classes. It resides in the underlying injectors / DI framework(s) instead. • Example: Servlets (see MongoDBWeb app class example) • Observer pattern: The control is transferred from the observers to the subject when it comes to reacting to changes. • Example: Exercise - write an example • Template method pattern: The control resides in the base class that defines the template method, instead of in the subclasses, implementing the algorithm’s steps. • Example: JUnit Mongo Inversion of Control More Design Patterns REVIEW WHAT IS A DESIGN PATTERN? • An abstraction that defines high level • Relationships between components • Actors • Reusable • Independent of implementation • Encapsulates knowledge already learned • When you face a problem, consider existing patterns that are applicable: saves you from re-inventing the wheel and making the same mistakes as others • Patterns are the language by which system architecture and design are expressed and shared. Mongo Inversion of Control More Design Patterns KINDS OF DESIGN PATTERNS • Based on the problem they solve, they classify as: • Creational • Singletion, Builder, Factory, ... • Structural • Adapter, Composite, Decorator, ... • Behavioral • Strategy, Observer, Visitor, ... • Applied at large scale design, they often combine to form enteprise design patterns. • Dependency injection • Command Query Responsibility Segregation • Domain Driven Design • Chain of reponsibility, aggregation and branching • ... and many more! Mongo Inversion of Control More Design Patterns CHAIN OF RESPONSIBILITY • Motivation • In writing an application of any kind, it often happens that the event generated by one object needs to be handled by another one. • Morover, the object which needs to handle the event migt be private/protected. • Solution: Use the Chain of Responsibility. • Allow an object to send a command without knowing what object will receive and handle it. • The request is sent from one object to another making them parts of a chain and each object in this chain can handle the command, pass it on or do both. • Popular example: coin slot in the vending machine ... • Intent: • It avoids attaching the sender of a request to its receiver, so other objects can handle it too • The request is sent from one object to another across the chain until one of the objects will handle it. Mongo Inversion of Control More Design Patterns CHAIN OF RESPONSIBILITY UML Mongo Inversion of Control More Design Patterns APPLICABILITY AND EXAMPLES • Having so many design patterns to choose from when writing an application, it’s hard to decide on which one to use, so here are a few situations when using the Chain of Responsibility is more effective: • More than one object can handle a command • The handler is not known in advance • The handler should be determined automatically • It’s wished that the request is addressed to a group of objects without explicitly specifying its receiver • The group of objects that may handle the command must be specified in a dynamic way Mongo Inversion of Control More Design Patterns CODE EXAMPLE:ASSIGNMENT 1 class Actor extends Endpoint implements HttpHandler { @Override public void handle(HttpExchange r) throws IOException { try { if (r.getRequestMethod().equals("GET")) { if (requestURI.equals(getActorURI)) { getActor(r); } else {statusCode = 405;} } else if (r.getRequestMethod().equals("PUT")) { ... } else {statusCode = 405;} } catch (Exception e) {...} Mongo Inversion of Control More Design Patterns EXERCISE A SHIPPING SYSTEM FOR ELECTRONIC ORDERS • The steps to complete and handle the order differs form one order to another based on : • the customer, • the size of the order, • the way of shipment, • the destination, • and more other reasons. • The business logic changes also as special cases appear, needing the system to be able to handle all cases. • Using CoR, solve the problem, by identifying: • the client • the command(s) • the handlers. Mongo Inversion of Control More Design Patterns COMMAND QUERY RESPONSIBILITY SEGREGATION Motivation Mongo Inversion of Control More Design Patterns COMMAND QUERY RESPONSIBILITY SEGREGATION • First described by Greg Young, it consists on separating the model to update information from the model you use to read information. • The mainstream approach people use for interacting with an information system is to treat it as a CRUD datastore. • As our needs become more sophisticated we steadily move away from that model. • We may want to look at the information in a different way to the record store, perhaps collapsing multiple records into one, or forming virtual records by combining information for different places. • The change that CQRS introduces is to split that conceptual model into separate models for update and display, which it refers to as Command and Query respectively. Mongo Inversion of Control More Design Patterns COMMAND QUERY RESPONSIBILITY SEGREGATION Mongo Inversion of Control More Design Patterns DOMAIN DRIVEN DESIGN AGGREGATE PATTERN • Aggregate is a pattern in Domain-Driven Design. • A DDD aggregate is a cluster of domain objects that can be treated as a single unit. • Example: an order and its line-items • An aggregate will have one of its component objects be the aggregate root. • The only public member of an aggregate is the aggregate root. • The root can thus ensure the integrity of the aggregate as a whole. • Aggregates are the basic element of transfer of data storage - you request to load or save whole aggregates. Transactions should not cross aggregate boundaries. Mongo Inversion of Control More Design Patterns AN AGGERGATE EXAMPLE Mongo Inversion of Control More Design Patterns AN EXAMPLE:SOCIAL GRAPH • When Jason follows Gloria, we create a Follow relationship between nodes. • Note that, in this design, each Person is not an Aggregate. • A Person doesn’t have a consistency boundary. One transaction modifies two Persons. • Question: count followers and followees. Mongo Inversion of Control More Design Patterns SOCIAL GRAPH:AGGREGATE DESIGN Mongo Inversion of Control More Design Patterns SOCIAL GRAPH:AGGREGATE DESIGN • We can model the social graph with Aggregates by separating followership from followeeship. • Now, Jason’s and Gloria’s Person objects are both Aggregates. They contain private Follower and Followee objects that contain references to other Person objects. • But because there are two different aggregates, we need two different database transactions when Jason follows Gloria: • We add a Followee, referencing Gloria, to Jason and update Jason’s followee count. • We add a Follower, referencing Jason, to Gloria and update Gloria’s follower count. Mongo Inversion of Control More Design Patterns REFERENCES Fowler Sarin.