question: a bookshop maintains the invertory of books that are being sold at the shop. the list includes the details such as author,title,price,publisher and stock position. whenever a customer wants a book the sales person inputs the title and author and the system seaches the list and displays whether it is available or not. if it is not,an appropriate message is displayed. if it is then the system display the book details and the number of copies required.if the requested copies are available the total cost of the requested copies is displayed, otherwise the message"required copies not in stock" is displayed.

design the system using a class called books with suitable member functions. improve the system design to incorporate the folllowing features.
a) the price of the book should be updated as and when required. use a public member function to implement this.
b)the number of copies of each book currently available should be automatically updated as soon as a transaction is completed.
c)the number of successful and unsuccessful transactions should be recored for the purpose of statistiacl analysis.

Do you have any data or input file content to work with?

Also, it seems that a Book would also have an ISBN.

You need to tactfully tell your instructor that the requirement for calling the class "books" is ABSOLUTELY STUPID. One would, by necessity of basic design requirements, need to implement a "Book" class, which is most decidedly singular and then, if so desired per the needs of the design, implement a "BookRepository" class that stores and manages the various books contained within the repository AND then create a "books" variable of type BookRepository.

The basic fact that the instructor seems to want all of this "work" to be done in what appears to be a single class called "books" is absurd. At best, it is completely juvenile. One of the basic concepts behind OOP is the notion of modeling "real world things" in code. How does one model a "books?" What one thing is a plurality of items? ...in C++ we call it a container.

The one thing that we really DO NOT WANT TO DO is to overlap responsibility between what is a "Book" and what do we need to do to manage an inventory of books. These requirements seem to suggest that overlapping these responsibilities is not only expected, but preferred. A "Book" as an entity should encapsulate all that is and is representative of what it takes for us to capture the data useful in describing and "recreating" the book in terms of our data needs for it. It isn't a manner of telling us how many successful or unsuccessful book sales transactions happened. That is some activity that we perform EXTERNALLY on Book(s) and it should not be a part of "Book."

Another aspect of complete absurdity is the notion that a "Book" should contain some idea of "stock position." That is a function of whatever management infrastructure is used to manipulate the inventory of Book(s). If you imagine a single, real-world book, what does it "know" about how many of it were reproduced? Sure, we can see that it can "tell" us the number of pages, its title, author, ISBN, hard or soft cover, maybe even size, copyright date(s), edition(s), but it should definitely NOT have any concept of how many of it were printed (or are currently in inventory). Also, the "Book" should NOT have a notion of the "price" beyond that of the "cover" price. Whether the book seller is a wholeseller or a retailer will determine the individual unit price, and for the most part, it will be based somewhat on the cover price of the book. Therefore, it is YET ANOTHER external "action" that we perform based on a current instance of a book. Here is some pseudo-code:


The code above demonstrates that there is a need for an individual "Book," a collection of Book(s) and a management/user interface/decision-support system for the collection.


:davis: