1 of 35

BARGAIN BIN QUIZLET

BBQ

Aryan, Anthony, Edward, Junyu, Justin, Lucas, Thomas, Winston

2 of 35

PROJECT OVERVIEW

3 of 35

SOLID PRINCIPLES

Single responsibility principle (SRP)

All use cases are self-contained; only basic entities and data access classes are used globally
All other classes (use case interactors, presenters, controllers etc.) handle aspects of only one use case

Open/closed principle (OCP)

The addition of future features does not require modification to existing classes

Liskov substitution principle (LSP)

For example, subclasses of Quiz Question can operate as functional substitutes.

4 of 35

SOLID PRINCIPLES

Interface segregation principle (ISP)

Input / output boundaries contain no more than the minimum required methods for use case functionality
Three data access interfaces; one to handle each kind of stored entity

Dependency inversion principle (DIP)

Input / output boundaries are used so inner Clean Architecture layers do not depend on the outer layers

5 of 35

CODE ORGANIZATION

organized by clean architecture layer
proper naming convention for all classes and packages

6 of 35

CODE SMELLS

No Alternative Classes with Different Interfaces

Good Communication to avoid the replicated code

Avoided Bloaters

Primitive Obsession
Large Class
Long Parameter List

No Temporary Field and Dead Code

Eradicated Warnings of Unused Methods

No Inappropriate Intimacy and Middle Man

No extraneous code other than what is required by Clean Architecture and use of CA interfaces to reduce Inappropriate Intimacy

7 of 35

FEATURES

SIGNUP AND LOGIN

01

HOMEPAGE AND DATABASE

02

CREATE / DELETE FLASHCARD SET

03

CREATE / DELETE FLASHCARD

04

EDIT FLASHCARD / FLASHCARD SET

05

STUDY MODE

06

QUIZ MODE

07

SEARCH FOR A FLASHCARD SET

08

8 of 35

REGISTRATION / SIGNUP

01

Aryan

DEMO

Functionality

User Signup

Admin User Signup

Error Handling

Existing Username, Incorrect Repeat Password, Incorrect Filled AdminKey

CHALLENGE

Differentiating between the creation of User and AdminUser with adherence to Clean Architecture

LEARNING

Introduction to the implementation with Clean Architecture that ensures SOLID Principles with inspiration

Single responsibility principle (SRP): Each class is responsible for 1 specific task, for example interactor is meant to deal with the attributes but its still 1 task and otherwise each class still has one responsibility.

Open/closed principle (OCP): Having the user and common user classes in the entities segregated aspect allows for this principle as even in other code it treats themselves as an extension of the code rather than directly interacting and altering it. Hence, allowing for stronger implementation of this principle.

Liskov substitution principle (LSP): Having common user be heightened usage of the user class allows for this principle as it allows for the implementers to modify the code with the common user class but doesn't modify or remove the basic foundation of the program and this use case.

Interface segregation principle (ISP): Having the input and output boundary interfaces keep a minimal element to them to conduct only the absolute necessary and not expanding beyond allows for this principle. Thus this implementation allows for re-implementation in other aspects of the code to not impact as much.

Dependency inversion principle (DIP): Using attributes of the clean architecture with the data boundary interfaces, data access interfaces and controllers/presenters allow for this principle as there is as far from a direct relation within higher-level classes to lower-level classes through these abstraction layers mentioned previously.

9 of 35

LOGIN

01

Aryan

DEMO

Functionality

User Login

Error Handling

Incorrect Username,

Incorrect Password

CHALLENGE

Not directly constructing the database mimicking real life software development.

LEARNING

GitHub communication / reviewing and database referencing

Single responsibility principle (SRP): Each class is responsible for 1 specific task, for example interactor is meant to deal with the attributes but its still 1 task and otherwise each class still has one responsibility.

Open/closed principle (OCP): Having the user and common user classes in the entities segregated aspect allows for this principle as even in other code it treats themselves as an extension of the code rather than directly interacting and altering it. Hence, allowing for stronger implementation of this principle.

Liskov substitution principle (LSP): Having common user be heightened usage of the user class allows for this principle as it allows for the implementers to modify the code with the common user class but doesn't modify or remove the basic foundation of the program and this use case.

Interface segregation principle (ISP): Having the input and output boundary interfaces keep a minimal element to them to conduct only the absolute necessary and not expanding beyond allows for this principle. Thus this implementation allows for re-implementation in other aspects of the code to not impact as much.

Dependency inversion principle (DIP): Using attributes of the clean architecture with the data boundary interfaces, data access interfaces and controllers/presenters allow for this principle as there is as far from a direct relation within higher-level classes to lower-level classes through these abstraction layers mentioned previously.

10 of 35

HOME SCREEN

02

Justin

Displays a top bar

Includes search, add flashcard sets, log off buttons

On the home screen itself displays the users flashcard sets

Includes buttons to study, edit, test, and delete the flashcard set

11 of 35

LEARNING

Displaying all the data into one screen

12 of 35

DATABASE

02

Justin

CHALLENGE

Figuring out what design principle to use to build the data access classes in order to adhere to SOLID.

DEMO

Functionality

Reads and writes data from and to the database

Error Handling

Has the ability to read csv file with a delimiter specified in the value itself

LEARNING

Adapting a facade design pattern to the creation of the data access classes and the gateway itself.

13 of 35

CREATE/DELETE FLASHCARD SET

Edward

Creation screen
Error handling
Successful creation

————————————————————————————————————————

Flashcard Set

Deletion screen
Confirmation
Successful deletion

03

14 of 35

DEMO

Edward

Create (0:00-0:30)

Delete (0:30-0:47)

03

15 of 35

IMPLEMENTATION CHALLENGE

Edward

Initial design:

New design:

Use case interactors

Flashcard Set data access

Flashcard Set database

Use case interactors

DBGateway

(a Facade)

Flashcard Set database

Flashcard database

User database

03

16 of 35

CREATE FLASHCARD

04

Junyu Chen

Creating with valid term and definition.

17 of 35

CREATE FLASHCARD

04

Junyu Chen

Creating with duplicate term.

18 of 35

CREATE FLASHCARD

04

Junyu Chen

Creating with invalid term or definition.

19 of 35

DELETE FLASHCARD

04

Junyu Chen

20 of 35

CREATE / DELETE FLASHCARD

04

Junyu Chen

Challenges/Learning

Clean Architecture
Github

21 of 35

EDIT FLASHCARD AND FLASHCARD SET

05

Thomas Shim

Edit the title and description of a flashcard set.

If title edit is empty, an error message pops up.

If edit complete a success message pops up with edited term and definition

22 of 35

EDIT FLASHCARD AND FLASHCARD SET

05

Thomas Shim

Edit the term and definition of a flashcard

If term edit is empty an error message pops up

If edit complete a success message pops up with edited term and definition

23 of 35

EDIT FLASHCARD AND FLASHCARD SET

05

Thomas Shim

Challenge faced/Learning

Learning to adhere to Clean Architecture

Roles of each class and why we need them

24 of 35

EDIT MAIN PAGE (view flashcard)

05

Thomas Shim

A user interface that shows:

All flashcards in the selected flashcard set

Edit features

Edit
Delete
Add
Refresh

25 of 35

EDIT MAIN PAGE (view flashcard)

05

Thomas Shim

Challenge faced/Learning

Bringing all use cases together

Simple due to clean architecture

Java swing, UI

26 of 35

STUDY MODE

06

Lucas

This feature allows a user to study a non-empty flashcard set
Sort: creation order, alphabetical order, or by random shuffle
In Order / Reverse
Display Term / Definition
Cycle forwards / backwards through a flashcard set and ‘flip’ each flashcard to see the other side

27 of 35

STUDY MODE

06

Lucas

CHALLENGE

How to build a complex entity out of stored data and allow the client to interact with this data without violating Clean Architecture. Solved with a builder design pattern

LEARNING

Effective communication with my team members

28 of 35

QUIZ MODE

07

Anthony

Text Entry

True False

Multiple Choice

Timer

Detailed Quiz Results

29 of 35

30 of 35

CHALLENGE

Learning how to implement clean architecture classes.

31 of 35

SEARCHING COMMUNITY FLASHCARDS

08

Winston

Public Flashcard Sets
Search Input and Tags
Results Screen
Admin Control

32 of 35

SEARCHING COMMUNITY FLASHCARDS

08

Winston

33 of 35

LEARNING

Connecting Use Cases

34 of 35

FUTURE WORK TO BE DONE

Text-to-speech.
Audio reader.
Calendar that schedules study sessions and quizzes.
Email notifications.
SQL database storage instead of CSV.
Web server + client interaction.
Monetization and paid subscription.

35 of 35

end

questions?