While we don't explicitly use 2D arrays or their algorithms in our Java code, we do go about manipulating the database with the concepts and methodology that we would with 2D arrays. In this FRQ, we get the sum of each row and compare rows to each other to check for diversity. While we don't get the sums of our database rows, we do compare them. Below is an example of our Company database and how it compares rows to each other (not including frontend code as it is not part of the topic or context):
Company.java:
CompanyController.java:
CompanyRepository.java:
As seen in the three Java files that make up the Company database, we have control over comparing different rows to each other. However, going beyond the algorithm of the FRQ, we can compare rows based on any certain property and not just the sum of each row. This is very useful for administrative control, user database manipulation, and more.
Question 2:
It is tough to write good Java code without the use of List/ArrayList algorithms. That's why whether we use them or not in our code is out of the question, as there are too many examples to list here of the applications of these algorithms. However, one key example is found in our Employee database, where employees represent users in our project. While the employee POJO doesn't need list algorithms, the controller and servicing class do. Below is a demonstration of how that works:
EmployeeController.java:
EmployeeRepository.java:
As you can see in the code, the lists in each class are being manipulated with the same algorithmic conceptual thinking as in the FRQ, proving the connection between the FRQ and our project.
Question 3:
There is no question of whether or not we incorporate methods and control structures. Everything in our backend is object-oriented programming, therefore methods and control structures will never not be present. However, the algorithms present in this particular FRQ have specific examples in our project backend.
Below is a specific example in CompanyController.java of how we use our own getValueAt() method, but for our database instead:
And an example of our version of the removeColumn() from the FRQ in our project, is found in an example I'd like to give from EmployeeController.java:
As you can see, the @GetMapping methods in CompanyController.java use the same algorithmic logic as the getValueAt() method in the FRQ, and the @DeleteMapping annotated methods in EmployeeController.java are parallel to removeColumn() in the FRQ.
Question 4
Although we don't use interfaces in our project, we do use the use of classes, and we use the concepts from APCSA to dictate how the child classes and parent classes, depending on who they inherit, should interact with each other. An example of this can be found in our JWT algorithms. Below is an example of how the JWT controller, authentication, authentication filter, request filter, and token utility classes interact, and how JwtAuthenticationEntryPoint.java has the same interface algorithms as the FRQ.
JwtAuthenticationEntryPoint.java:
As you can see, this class uses interface algorithms when it overrides the commence() method.
JwtApiController.java:
JwtAuthenticationFilter.java:
JwtRequestFilter.java:
JwtTokenUtil.java:
As you can see, the JWT classes within the backend use the same conceptual algorithmic programming as seen in APCSA FRQs such as Question 4.
[X] Specify type of FRQ: Method and Control Structure, Classes, Array/ArrayList, 2D Array
[X] Finish incomplete parts so that the FRQ runs
[X] Blog about key algorithm and how it matches FRQ type
[ ] Show runtime outputs in blog
Wasn't working initially but was fixed during class
3.95/4
45% FRQ associations 4/3.6 on indicators. Show how FRQs or principles of FRQs are incorporated into to your final project.
[X] Blog or describe how PBL/CB are teaching similar concepts in regards to Java.
[X] Expecting clear, well described, and well formatted associations between FRQ to Java Code contained in final project.
[X] Focus in on key themes for associations, i.e. if theme of FRQ is 2D array and you specify key algorithm, show how 2D array usage in final project is similar.
4/4
Overall notes
You put a lot of effort into this since you solved the question without looking at external sources and fixed the code after
A lot of code was provided in the associations issue which shows that you clearly understand the CB FRQ and know how to connect it back to your project
For the formating of the associations issue you could have only included the code that corresponds to the question rather than the entire block of code
Although your code ran in VS Code you should fix your notebook so it shows the results of what was ran
On these types of comparison the code is rather large. You could do this by...
Stating that "Tables and 2D array are a very strong association"
Illustrating a small piece of code that is specific to your point and then have way to show/hide the entire method
Be sure that your comparison is real specific, for instance in 2D array and SQL table, what exactly make the code or use case similar.
What made you choose a 2D array over a table... Mostly likely because Table allows for persistence, POJO allows for mix of data types, and Spring provides methods to move entity data to JSON for transport to frontend.
Question 1:
While we don't explicitly use 2D arrays or their algorithms in our Java code, we do go about manipulating the database with the concepts and methodology that we would with 2D arrays. In this FRQ, we get the sum of each row and compare rows to each other to check for diversity. While we don't get the sums of our database rows, we do compare them. Below is an example of our Company database and how it compares rows to each other (not including frontend code as it is not part of the topic or context):
Company.java:
CompanyController.java:
CompanyRepository.java:
As seen in the three Java files that make up the Company database, we have control over comparing different rows to each other. However, going beyond the algorithm of the FRQ, we can compare rows based on any certain property and not just the sum of each row. This is very useful for administrative control, user database manipulation, and more.
Question 2:
It is tough to write good Java code without the use of List/ArrayList algorithms. That's why whether we use them or not in our code is out of the question, as there are too many examples to list here of the applications of these algorithms. However, one key example is found in our Employee database, where employees represent users in our project. While the employee POJO doesn't need list algorithms, the controller and servicing class do. Below is a demonstration of how that works:
EmployeeController.java:
EmployeeRepository.java:
As you can see in the code, the lists in each class are being manipulated with the same algorithmic conceptual thinking as in the FRQ, proving the connection between the FRQ and our project.
Question 3:
There is no question of whether or not we incorporate methods and control structures. Everything in our backend is object-oriented programming, therefore methods and control structures will never not be present. However, the algorithms present in this particular FRQ have specific examples in our project backend.
Below is a specific example in
CompanyController.java
of how we use our owngetValueAt()
method, but for our database instead:And an example of our version of the
removeColumn()
from the FRQ in our project, is found in an example I'd like to give fromEmployeeController.java
:As you can see, the
@GetMapping
methods inCompanyController.java
use the same algorithmic logic as thegetValueAt()
method in the FRQ, and the@DeleteMapping
annotated methods inEmployeeController.java
are parallel toremoveColumn()
in the FRQ.Question 4
Although we don't use interfaces in our project, we do use the use of classes, and we use the concepts from APCSA to dictate how the child classes and parent classes, depending on who they inherit, should interact with each other. An example of this can be found in our JWT algorithms. Below is an example of how the JWT controller, authentication, authentication filter, request filter, and token utility classes interact, and how
JwtAuthenticationEntryPoint.java
has the same interface algorithms as the FRQ.JwtAuthenticationEntryPoint.java:
As you can see, this class uses interface algorithms when it overrides the
commence()
method.JwtApiController.java:
JwtAuthenticationFilter.java:
JwtRequestFilter.java:
JwtTokenUtil.java:
As you can see, the JWT classes within the backend use the same conceptual algorithmic programming as seen in APCSA FRQs such as Question 4.