Last week

• Mediator & Observer recap and comparison
• State
• Strategy
• Bridge, State and Strategy comparison
• Template Method

Week 1

Week 2

SOLID principles

Creational patterns

• Factory
• Builder
• Prototype
• Singleton

Structural patterns

• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Proxy

Week 3

Behavioral patterns

• Chain of Responsibility
• Command
• Iterator
• Mediator
• Observer

Week 4

Behavioral patterns

• State
• Strategy
• Template Method

Today’s agenda

Recap

Notes before

• Anonymous feedback form
• Final course of the semester to be held @ accesa
• Str. Constanta, nr. 12
• 19th of January, 2018
• Guest speaker: Alex Boga
• Technical lead @accesa
• Java trainer @Scoala Informala de IT

​

Week 1

Week 2

SOLID principles

Creational patterns

• Factory
• Builder
• Prototype
• Singleton

Structural patterns

• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Proxy

Week 3

Behavioral patterns

• Chain of Responsibility
• Command
• Iterator
• Mediator
• Observer

Week 4

Behavioral patterns

• State
• Strategy
• Template Method

App design

The practical app design will iterate over 3 repetitive steps:

• Client request
• Technical decision of implementation
• Implementation

Client request

• Create a service that will return a university type entity, depending on the input given
• “Student” keyboard input will return a Student entity
• “Secretary” keyboard input will return a Secretary entity
• “Professor” keyboard input will return a Professor entity

Client request

• Entities should have ID, first name, last name
• Students should have year of enrollment
• Secretary and Professor should have salary
• Professor should have title

Technical decision of implementation

• Create a service that will return an entity based on user input given at runtime
• Factory should be used, in its forms:
• Simple Factory
• Factory Method
• Abstract Factory
• Factories should be managed by a Service, whose instantiation should be manager by a ServiceManager

Implementation

• ​

Client request from new client

• Create same people management app, but in the business domain of a Company, instead of University
• Entities should still have IDs, first names and last names
• Create a service that will return a university type entity, depending on the input given
• “Worker” keyboard input will return a Worker
• “Manager” keyboard input will return a Manager
• Worker should also have a salary and job title
• Manager should also have a salary and managerial position

Technical decision of implementation

• The logic for creating University entities will remain the same
• The logic for creating Company entities is new and could be added alongside for the new client
• For this case, we can extend the AbstractFactory, to also return a CompanyFactory

Implementation

• ​

Client feature request

• Monitor activity of created and accessed entities
• When an entity is created, the same behavior applies as before, however, the entity is also monitored
• Server logging should be done for any activity done on the entity

Technical decision of implementation

• We need to allow the same behavior as before, but extend functionality

​

• We can use the Proxy to wrap around the Entity

​

• To extend the current functionality with the Proxy, we can use an Adaptor

Implementation

• ​

Client feature request

• Entity hierarchy for company domain

​

• A service should structure entities in a hierarchy based on their company hierarchy

Technical decision of implementation

• What pattern could we use to illustrate the Hierarchy of entities?

​

Final implementation

• ​

Thank you for your attention!