Open Christopher-LM opened 4 years ago
You are right and this is indeed a flaw. Previously our team decided that book names and isbns should both be different for different books. We also rejected duplicate books. However, when we are moving towards the end of tp, we changed that convention because we want to make it more realistic - in reality, different books can share the same name, so we twisted our implementation to be that book names can be the same whereas book isbns must be unique. It is a flaw that we did not update usageBy feature. However, this issue is not as severe because we also enabled check usage by isbn so there will always be a substitute, which will always be correct when using. What is more, though in reality, book names can collide, but it happens very rarely. Even though there are collided book names, our system will not crash or throw error message on right input, so, this issue will not cause great problems.
Team chose [severity.Low
]
Originally [severity.High
]
Reason for disagreement: Perhaps I was too harsh with the severity level and I would like to lower it to 'medium'. The argument that the program has another command check usage by isbn does not decrease the severity of the flaw in check usage by name. By stating that "there will always be a substitute, which will always be correct when using." gives me the impression that just because another command A is able to do a similar function as another command B, the flaws of command B can be overlooked as we can always use command A. I think that this defeats the purpose of having command A in this case since users should always use command B and command A can be removed entirely from the program. From the CS2103 website, a medium severity is "a flaw that causes occasional inconvenience to some users but they can continue to use the program." Here, you mentioned that book names can be the same, and in fact it is not uncommon to find multiple books sharing the same title name. The command check usage by name would always return the number of times borrowed for one of the books matching the name. Personally, the team should reconsider the design of this command and can perhaps implement a check if there exists multiple books matching the name keyed in. Hope this helps!
No details provided.
There should be a check to see which book the user is referring to when more than one book share the same name, instead the command goes thru and returns the number of times borrowed for one of the books matching the name keyed in the command 'usageBy n/test01'