Design a set of types that represent the items that can be borrowed at a library.
This library offers books, CDs, DVDs, and Blu-ray discs. Some items can be downloaded as e-books, audio or
All items share a title and an ISBN. Books have an author and a number of pages. CDs, DVDs and Blu-ray
discs can hold multiple tracks of audio or video, each having a separate title and artist as well as a duration.
Task is to design a set of types that can be used to retrieve the information mentioned above
representing these various kinds of items. Please use constructs such as inheritance, interfaces and virtual
methods as you deem appropriate. You do not need to code the implementation of any methods and you
also do not need to deal with the different file formats for downloading. Diagrams are appreciated.
How do i design? and using what tool? and what do i have to design?
The only tools you need are a pencil, paper and an eraser.
When you have a description of the problem domain, you can start by writing down the nouns of the description, and how they interact with each other through verbs. You can then eliminate terms that are not related to the problem, or are too simple to be represented by a class. I condensed your problem description to the following sentences:
Books, CDs, DVDs and Blue-ray discs are items.
A library offers items.
Items have a title and an ISBN.
Books have an author and a number of pages.
CDs, DVDs and Blu-ray discs are discs.
Discs hold multiple tracks of audio or video.
Tracks have a title, artist and duration.
Relationships expressed by the verb 'to be' can be modeled by inheritance. For example, a Book extends an Item, and a CompactDisc extends a Disc.
Relationships expressed by a verb that indicates possession, such as 'to have' or 'to hold' can be modeled by a field inside the class. For example, a Track has a field that refers to a Duration.
Other verbs can be modeled by a method inside the class. You might have to mangle the verb a bit to get to a proper design. You also need to be creative and keep the real-world problem domain in your mind. For instance, the sentence "A library offers items" can be modeled inside the Library class by a method "Optional<Item> loan(Isbn isbn)" that takes the ISBN of the item you want to loan, and optionally returns an instance of the item that you want to loan (it might not return an item if the library is out of copies). This particular example is probably a little bit too advanced for your assignment, but you might use it as inspiration.
Do not be tempted to use primitive types unless the field is REALLY primitive. For instance, don't use String to represent an artist. Use an Artist class, which you can leave empty in the first stage of your design. Properties that are REALLY too primitive to be represented by a separate class include the number of pages of a book, which you may represent with an int.
On a sheet of paper, draw a box for every noun you've extracted as a type from the description. At the top of the box, write the noun that the box represents. Inside the box, write the fields and the methods that you believe the class should contain. Draw arrows between boxes that have a relationship with each other, and next to the arrow write down what the relationship is. For instance, an arrow between a Book and an Author can be annotated with "written by" or "writes", depending on the direction of the arrow.
Finally, when you're happy with your design, you can use an UML tool to make a nice diagram of your design, to include with the solution of your assignment. Make sure to explain your design and choices.
Stephan van Hulst wrote:The only tools you need are a pencil, paper and an eraser.
And about 3 pounds of gray matter.
When you have a description of the problem domain, you can start by writing down the nouns of the description, and how they interact with each other through verbs. You can then eliminate terms that are not related to the problem, or are too simple to be represented by a class.
That's how many people are taught design. My experience, however, is that this process leads to confusion and over-engineering. I like to start with tasks and description of outcomes. Then work my way backwards, identifying information I need to complete those tasks, then figure out how to arrange that information around the tasks and then organize the tasks+information around various entities that might collaborate with each other.
Let nothing stop you! Not even this tiny ad:
a bit of art, as a gift, the permaculture playing cards