W6 Flashcards
(20 cards)
What is a Use Case?
It is an individual action that a user can take when interacting with your program.
A user story strings together a number of use cases. So you can think about a use
case as a complete action taken by the user during a user story
What is an Entity?
This is a class that stores information about the building blocks of your
program and contains the enterprise business rules of your program. For example, in
a program like ACORN, the building blocks would be Students, Courses, etc. Any rule
that impacts students across U of T, and is true for all U of T software including
ACORN is called an Enterprise Business Rule. For example, the fact that a student
cannot change their student number should be reflected by the methods inside the
Student class
What is an Use Case Interactor?
This is a class that manipulates information in the entity
classes to accomplish an individual use case. This class implements the Input
Boundary Interface. This class encorporates the Application Business Rules. Does
your app (say ACORN) allow you to enrol in more than 7 courses? The answer to that
question should be built into a Use Case Interactor (say the EnrolmentInteractor)
and not an Entity
What is Input Data Object
This object is created by a Controller to pass information from the user to the Use Case Interactor. It stores data
What is Input Boundary Interface
This interface is implemented by a Use Case Interactor class. It allows the Use Case Interactor to be replaced without impacting the Controller class that calls the methods in this interface. It also allows the Controller to be unit tested by allowing the test to “mock” the Use Case Interactor
What is Output Data Object
This object is created by the Use Case Interactor to pass information from the back end of your program to the presenter without having any dependencies between an entity and an interface adapter. It stores data.
Output Boundary Interface
This interface is implemented by the Presenter. It allows the Use Case Interactor to call methods that are implemented in the Presenter without being directly dependent on that class. It also allows us to unit test the Use Case Interactor by “mocking” the Presenter.
Data Access Interface
This interface allows the Use Case Interactor to call methods in a Data Access Object without breaking the Clean Architecture dependency rule. It also prevents changes to the way data is stored to affect the Use Case Interactors. To unit test the Use Case Interactor, this interface allows us to “mock” a Data Access Object
Data Access Object
This object reads and writes persistent data to a file or database outside the program
Controller
A Controller class takes information from the user (examples: text that is entered from the keyboard, a button click, a menu option that is selected, etc.). Then the controller calls the Use Case Interactor methods associated with that information, giving it an instance of an Input Data Object containing whatever information from the user that the Use Case Interactor requires. For example, if you have “back” and “exit” buttons, you will likely have a “BackNavigationController” and an “ExitAppController”. If you have a textbox, there is a Controller reading the String(s) that the user types and putting them in an Input Data Object to pass to a Use Case Interactor.
Presenter
A Presenter class receives information (an Output Data Object) from the Use Case Interactor and sends it to the front end by leaving it in a View Model or allowing the View to access it directly
View Model
This is a storage class for information the View needs to display. Does the View display the currently logged-in user’s name? Then the View Model stores that name. Want to know which colour scheme the logged-in user prefers? The colours are stored in the View Model as Strings, RGB hexadecimal codes, or something else. The View accesses the View Model for any information it needs.
View
This is any part of the program that the user can see, hear, or interact
with directly. This includes buttons, JFrames, text fields, pop-up windows, etc.
What is the Dependency Rule in Clean Architecture? Which dependencies does it
allow?
The Dependency Rule in Clean Architecture says that classes can only depend on
something with the same or higher level of abstraction. In other words, the outside
layer can depend on the most immediate inside layer, but not the other way around.
It says that anything in the Frameworks and Drivers layer can depend on each other
or the Interface Adapter layer; the Interface Adapters can depend on each other or
Use Case Interactors; Use Case Interactors can depend on each other or Entities;
Entities can depend on each other and nothing else; no other dependencies are
allowed.
Enterprise Business Rules
Rules that are true across all programs in the same series or for the same company.
Examples: Mario is always red and Luigi is always green. No two students at U of T can have the same UTORid. etc.
These rules are implemented in Entity classes.
Application Business Rules
These rules are specific to your application.
In one application, maybe Mario and Luigi can swim if they are wearing a certain suit. In other applications, maybe they are not allowed to swim at all. These games would be part of the same Enterprise, but each application works a bit differently.
These rules are implemented in Use Case Interactors.
What are Interface Adapters
Controllers, Presenters, Gateways (including Data Access Objects) are interface adapters because they adapt the program to whatever platform it is running on and/or any external hardware or software with which your program interacts. These classes are inside your program.
What are Frameworks and Drivers?
These include any hardware or software outside your program with which your program interacts, such as a database, the internet, any APIs, a barcode scanner, a printer, etc. This also includes your View, since it does not have to be written in the same language as the rest of your program and can be considered “outside” of your program even if it is written in the same language.
For each SOLID principle, how does Clean Architecture follow it?
Single Responsibility Principle – By assigning one role only to each class (“Controller”, “Entity”, etc.) the number of potential sources of change is reduced.
Open/Closed Principle – Given all of the interfaces, it is possible to replace almost any class without requiring subsequent changes to the rest of the program. Also, to add a new feature, you add a new Use Case which can still depend on the old Entities, Data Access Interface, etc.
Liskov Substitution Principle – N/A since inheritance is not necessarily used. Interface Segregation Principle – Each interface is given one job (or service) and is required to have all the necessary methods for that one job (or service) and no others.
Dependency Inversion Principle – The Dependency Rule in Clean Architecture is a more detailed description of the Dependency Inversion Principle. They basically say the same thing.
What are the layers of CA from lowest to highest?
Frameworks and Drivers, Interface Adapters, Application Business rules, and Enterprise Business Rules
