I have about 4 years of experience writing Java code, and the provided solution looks like an amateur’s take on how to write OOP code. I am trying to be as constructive as possible but there are so many mistakes here:
- Why is the BookItem class inherited from the Book class? BookItem is not a “special” type of Book. The only reason why BookItem is inherited is to “reuse” code (so that fields like ISBN and title are not copied), but other than that, it does not make sense to do it. Instead, using composition here is a better approach. Provide the Book details as a constructor for the BookItem and keep it as a member.
- We have too much logic in the domain classes (Member, BookItem). The domain classes are calling static methods to accomplish certain tasks. I highly doubt that this approach will pass a code review in any credible company. Typically, we do not use static methods. We define service classes that encapsulate the logic and use dependency injection to inject and use them. Methods like checkout and lend should be defined in services, they should not be static. The code just violates the single responsibility principle in so many places. The only portion that seems to be properly implemented is the Catalog class.
The provided code is not unit testable (too many static methods) and is tightly coupled. Has anyone ever submitted a solution like this and passed?
Would love to know OOP experts’ opinion on the raised questions. Will try to code a better solution and post it here.