Biblioteca
A terminal catalog for exploring contracts and polymorphism.
Flow summarized from the reviewed implementation. Details and limits are explained below; this visualization is not a production screenshot or proof of measured performance.
Exercise objective
Biblioteca implements terminal-based catalog and inventory management. Physical books and e-books share display and update operations; a menu supports adding, listing, selling and deleting items.
It focuses on object organization and software contracts in a small domain. It is a programming exercise, not a complete lending or institutional library system.
Shared interface and concrete types
ILivro defines expected attributes and methods. LivroFisico and Ebook implement the contract; e-books add file size while retaining an interface the manager can use.
An ILivro list allows different objects to share operations. Display uses each class’s behavior, making polymorphism observable without conditioning every action on concrete type.
Catalog and stock rules
GerenciadorLivraria finds items by ISBN and rejects duplicate entries. Sales check stock and update quantities when the implemented condition is satisfied; deletion removes found items.
These methods centralize rules instead of repeating them in the menu. Positive quantities, bounds and required data still need validation; typing does not automatically prevent every invalid terminal input.
CLI and synchronous interaction
readline-sync receives options and values in a menu loop. Each option calls an operation and presents its outcome, making the exercise interaction readable.
Input is blocking and suits the local demonstration flow. An API or graphical interface would need another input adapter without necessarily rewriting all catalog rules.
Persistence and current boundaries
Items remain in the manager’s array and examples are inserted at startup. State exists only during the process; there is no database, persistent file or simultaneous multi-user control.
This boundary keeps the exercise focused on OOP. Interface-based persistence would be a coherent extension, enabling tests and storage without mixing SQL into the menu.
Learning and future verification
The project demonstrates classes, interfaces, collections, lookup, control flow and domain contracts. Review inspected the program without claiming nonexistent automated coverage.
Next steps include duplicate, sales and insufficient-stock tests, input validation and separating rules from console output. The public repository documents this learning foundation.