Dumitrache Andreea Ștefania 321CA

Assignment 2

Structure

Main packages:

• command: handles all commands
• ticket: manages tickets (Bug, FeatureRequest, UiFeedback)
• milestone: handles milestones
• history: tracks ticket history
• application: handles phase transitions
• user: manages users and their roles

Design Patterns

1. Singleton pattern

Classes that manage data about users, managers, tickets and milestones are singletons:

• UserManager, TicketManager, MilestoneManager, NotificationManager
• Ensures only one instance exists

2. Factory pattern

Used factories for creating objects:

• BugFactory, FeatureRequestFactory, UiFeedbackFactory create each ticket type
• TicketFactory picks the right factory based on type
• CommandFactory creates commands from input
• SearchPredicateFactory builds filter predicates
• Isolates creation logic

3. Builder pattern

For building complex tickets with many fields:

• TicketBuilder<T> generic abstract
• BugBuilder, FeatureRequestBuilder, UiFeedbackBuilder
• Each builder sets fields specific to its type (severity for Bug, businessValue for FeatureRequest)
• Handles optional fields

4. Command pattern

All commands extend Command abstract:

• Each command has execute() and getAllowedRoles()
• Easy to add new commands

5. Observer pattern

For the notification system:

• Observer interface with notify(String message) method
• User implements Observer (the observers)
• NotificationManager is the subject that holds the list of observers
• Users register with subscribe() and get notified when needed

6. Strategy pattern

For Search command I used filtering strategies:

• SearchPredicateFactory builds predicates
• Each filter is a class (BusinessPriorityPredicate, TypePredicate, etc)
• Can add new filters without modifying existing code

7. Template Method

For reports I made GenerateTicketReport abstract:

• Common flow is defined in the template (4 reports use it)
• Subclasses implement getReport() with their own logic

OOP Principles Used

Inheritance

• User extended by Reporter, Developer, Manager
• Ticket extended by Bug, FeatureRequest, UiFeedback
• TicketBuilder<T> extended by concrete builders

Polymorphism

• Commands execute through execute() without knowing the exact command type
• History events handled through TicketEvent interface

Encapsulation

• Private/protected fields with getters and setters
• Singleton managers with getInstance()
• Validations are in classes, not scattered through code

Abstraction

• Abstract classes: Command, User, Ticket, TicketBuilder
• Interfaces: Observer, TicketMetrics, TicketEvent
• Separated what a class does from how it does it

Generics

• TicketBuilder<T extends TicketBuilder<T>> so each builder returns its own type, not the generic one
• Predicate<Ticket>, Predicate<Developer> for filtering
• EnumMap and EnumSet for enum related data

Implementation details

Streams and Functional Programming

Used the following features:

• Filter, map for working with tickets and users
• Predicates that can be combined
• Supplier<Stream<T>> for reusable streams

Data Structures

• EnumMap: for maping enums
• EnumSet: for allowed roles in commands
• LinkedHashMap: for users in UserManager

Nested Enums

• Ticket.TicketType, Ticket.BusinessPriority
• Bug.Severity, Developer.Seniority
• Placed them in clases for clearer context

SOLID Principles

• Single Responsibility: TicketManager only manages tickets, NotificationManager only handles notifications
• Open-Closed: can add new filters (predicates) without modifying existing Search code
• Liskov Substitution: any Ticket subclass works where Ticket is expected
• Interface Segregation: small, specific interfaces like Observer which has just notify() method
• Dependency Inversion: histry tracking depends on the TicketEvent interface, not on specific event types