Rewiev of the project by Mirko Bandello
Review form
General
-
G1: How creative is the project? (
0
: I've seen this on Youtube,1
: not creative2
: average,3
: creative,4
: very creative,5
: wow!)- Answer: 4
- Justification: I have never heard about such a framework. Therefore, in my view it is very original.
-
G2: How difficult was it to implement the project? (
0
: no challenge,1
: very easy,2
: easy,3
: fair,4
: complex,5
: insane)- Answer: 4
- Justification: : Because there are a high number of packages and classes, where almost all classes implement one common interface, and there are a lot of child classes and constructor that depends on other constructors. Moreover, there is a wide use of lambda expression and streams to filter objects.
-
G3: List 3 positive aspects of the project. Motivate your selection.
- 1. Use of lambda expressions.
- 2. Use of streams and hashmaps to collect ingredients or recipes.
- 3. Well use of interfaces and abstract classes.
-
G4: List 3 negative aspects of the project. Motivate your selection.
- 1. There is not the possibility to run the jar file, which should incorporate the runner class, because the main manifest attribute is not specified in the pom.xml file. In my view, despite it is an API, it would be better also to create a runnable jar, whenever the user wants to run it.
- 2. Too many classes for changing quantity of nutrients and ingredients. I think would have been better to use the decorator pattern, which extends the feature of object without creating new abstract classes.
- 3. Maybe there is some useless overloading for some methods, for example in the package “dosableList” there is the boolean method called “add” which is overloaded, because the first method accepts an object of the interface IDosable and the second one accepts an object of the class Dosable, which implements the interface IDosable , so there could have been only one method .
Programming techniques
- PT1: Evaluate how well 5 programming techniques we learned throughout the course were adopted in the project. Assign a mark from
0
to5
to each technique, where0
means completely incorrect usage and5
means perfect usage.-
1. <: Method overriding>
- Answer: 5
- Justification: : because there are enough overriding techniques in classes. For example, the method “multiply”, in the class Dosable (of the Dosable package) is overridden both in the class Ingredient and Recipe. It is overriding because the signature is the same.
-
2.
- Answer: 3
- Justification: In my view, there is some useless overloading for some methods, for example in the package “dosableList” there is the boolean method called “add” which is overloaded, because the first method accepts an object of the interface IDosable . However is good as example to show overloading despite it causes redundance.
-
3.
- Answer: 5
- Justification: lambda expressions and method references have been used most with the Collections, therefore, since Collection is an interface the filter with predicates that don't throw an exception. Indeed, the functional interfaces in Java don't declare any checked or unchecked exceptions. So when they used the filter() method and lambdas , they(the developers of that code) didn’t put the try catch block for this reason , so it is perfect in this way.
-
4.
- Answer: 5
- Justification: There are two interfaces: IDosable and IRanking. Both are well structured, because no method is directly implemented inside those interfaces, but the methods are implemented by the abstract classes, which consequently are extended by the normal classes. So, there is a strong relationship between all them.In addition, The interface should have only static and final variables, but in these interfaces (IDosable and IRanking) there aren’t variables , so it is correct.
-
5.
- Answer: 5
- Justification: with abstract classes, you can also declare fields that are not static and final, and define public, protected, and private concrete methods. These conditions are all respected in the abstract classes of the project. Moreover each of the normal classes in the project extends only one abstract class for time. The project respects those principles and there is also a general type that helps classes to be better in relation with abstract classes.
-
1. <: Method overriding>
Git repository
- GR 1: How appropriate is the
.gitignore
file of the project? (0
: missing,1
: very bad,2
: bad3
: average,4
: good,5
: very good)- Answer: 5
- Justification: all .class are ignored.
- GR 2: How appropriate is the
README.md
file of the project? (0
: missing,1
: very bad,2
: bad3
: average,4
: good,5
: very good)- Answer: 3
- Justification: Good , but should have been included some maven instructions.
Maven
- M1: Can you compile the project via Maven? (
0
: no,1
: yes, but...,2
: yes)- Answer: 1
- Justification: : At the start I had a problem with the target version in the pom file, but I discovered it was my windows OS problem, since the new java version’s home variable path wasn’t uploaded. Then once I solved that I had these problems :
- Problem :
{
[ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] /Users/mirko/Desktop/prpr2021_foodgrinder/src/main/java/com/foodgrinder/baseClasses/dosables/Recipe.java:[12,8] com.foodgrinder.baseClasses.dosables.Recipe is not abstract and does not override abstract method subtract(com.foodgrinder.baseClasses.IDosable) in com.foodgrinder.baseClasses.IDosable [ERROR] /Users/mirko/Desktop/prpr2021_foodgrinder/src/main/java/com/foodgrinder/baseClasses/dosableLists/RecipeArrayList.java:[8,8] com.foodgrinder.baseClasses.dosableLists.RecipeArrayList is not abstract and does not override abstract method subtract(com.foodgrinder.baseClasses.IDosable) in com.foodgrinder.baseClasses.IDosable [ERROR]
… }
that Micheal quickly solved in the last git . So now the mvn clean install and mvn compile command work fine.
- M2: Can you clean the project via Maven? (
0
: no,1
: yes, but...,2
: yes)- Answer: 1
- Justification: The same reason of M1 .
- M3: Can you run the project via Maven? Check
README.md
on how to run the project. (0
: no,1
: yes, but...,2
: yes)- Answer: 1
- Justification: : yes it runs fine from the runner class, but I would like to create a jar file for each example.
- M4: Are the project's dependencies appropriately configured in
pom.xml
? (0
: no,1
: some,2
: yes)- Answer: 2
- Justification:
- M5: Are all Maven plugins appropriately configured in
pom.xml
? (0
: no,1
: some,2
: yes)- Answer: 2
- Justification: yes, they are.
- M6: Does the project adopt Maven's standard directory layout? (
0
: no,1
: yes, but...,2
: yes)- Answer: 2
- Justification: yes, it does.
Testing
- T1: Are all tests passing? Run
mvn test
. (0
: no,1
: yes, but...,2
: yes)- Answer: 2
- Justification:
- T2: How well do the tests cover the code? (
0
: no tests,1
: no important method,2
: some important methods,3
: most important methods,4
: all important methods,5
: 100% test coverage)- Answer: 5
- Justification:
- T3: Do the tests actually verify the expected behavior of the program? (
0
: no tests,1
: useless tests,2
: most don't,3
: some do, some don't,4
: most do,5
: awesome tests)- Answer: 5
- Justification:
- T4: How well can you understand what the tests are supposed to verify? (
0
: no tests,1
: what is going on?,2
: most are not understandable,3
: some are understandable, some aren't,4
: most are understandable,5
: all test are understandable)- Answer: 4
- Justification:
Documentation
- D1: How understandable is the Javadoc written for classes, fields and methods of the program? (
0
: no documentation,1
: very poor,2
: poor,3
: average,4
: good,5
: awesome)- Answer: 5
- Justification: It was written in an accurate way, and all classes had a Javadoc.
- D2: How useful is the Javadoc written for classes, fields and methods of the program? (
0
: no documentation,1
: irrelevant,2
: little utility,3
: average,4
: useful,5
: very useful)- Answer: 5
- Justification: There was an explanation for every method and each parameter inside it. The same for the classes and for the constructors.
- D3: Can you generate documentation files for this project? Run
mvn javadoc:javadoc
. (0
: no,1
: yes, but...,2
: yes)- Answer: yes
- Justification:
- D4: How adequate are the non-javadoc comments written throughout the code? (
0
: mostly inadequate,1
: average,2
: mostly adequate,3
: awesome)- Answer: 3
- Justification: they were written in a clear way and were useful.
Code quality
- Q1: Is the code style adopted throughout the project consistent? Consider how whitespace is represented (spaces or tabs), tab size, naming conventions for classes, methods and variables, indentation, braces usage, line width. See Google Java Style Guide as an example of code style guidelines. (
0
: no,1
: yes, but...,2
: yes)- Answer: 2
- Justification:
- Q2: How would you rate the project in terms of code duplication? (
0
: a lot of duplication,1
: some duplication,2
: barely any duplication,3
: no code duplication / only justifiable duplication)- Answer: 3
- Justification:
- Q3: How easy it is to understand how the program works by looking at the source code? (
0
: mostly hard to understand,1
: some fragments are hard to follow,2
: not hard, but not easy,3
: easy to understand)- Answer: 1
- Justification:
- Q4: Is any section of the program excessively inefficient? (
0
: mostly hard to understand,1
: some fragments are hard to follow,2
: not hard, but not easy,3
: easy to understand)- Answer: 1
- Justification:
- Q5: Does the program crash unexpectedly (e.g. by an uncaught exception)? (
0
: all the time,1
: rarely,2
: it happened once,3
: never)- Answer: 3
- Justification: