0

Suppose a Library System. if I think about Data, I can just distinguish Book, Member classes or at most Author or Publisher... (Are they only classes?), but I have some use cases, scenarios (Borrow, Deliver, Reservation...). Just I don't know when and how to distribute them in the mentioned classes, or should I introduce new classes

If I think of Single Responsibility and Separation of Concerns, they suggest me many other classes for any responsibility like Borrow for Borrowing, BookRepository to save and reserve book, etc ....

I would like to know how do you find the classes of this specific example or how do you use the Single Responsibility principle to find the classes.

The answer of this quesiton has some good points but it lacks a clarifying example.

Community
  • 1
Ahmad
  • 1,806
  • 3
  • 20
  • 32
  • possible duplicate of [Clarify the Single Responsibility Principle](http://programmers.stackexchange.com/questions/17100/clarify-the-single-responsibility-principle) – gnat Mar 10 '15 at 08:29

2 Answers2

2

There is a very simple analysis technique in which you write down the use cases in plain text and extract nouns and verbs. The nouns are likely to be essential concepts in your domain (so probably classes), the verbs are likely actions to be taken in the domain (so probably methods). This rule is not written in stone but it can help you get going. When I took courses in Object-Oriënted analysis they started us off on this method but it is something that you learn to do 'by heart' without thinking too much about it with some practice.

Let's look at an example*

A customer can make a reservation for a book in a library. To do this, he must check the availability of the book in the library. If the book is available for the period the user wishes to lend it he can make a lending with the library to lend the book for a given period.

Relevant Nouns

  • Customer
  • Reservation
  • Book
  • Library
  • Availability
  • Period
  • Lending

Relevant Verbs

  • Make (reservation)
  • Check (availability)
  • Make (lending)

This would lead me to a system where I have a Book class that belongs to a Library class. The Library class would also contain a list of Reservations and Lendings. On the Library there would be a method makeReservation that creates a Reservation for a Book during a Period. There would also be a makeLending that creates a Lending for a Book during a Period. Finally, a checkAvailability-method would be present that returns information on the availability of a Book during the Period.

The way you go about this is mostly a matter of personal preference. There are some guiding principles you could take into consideration while designing this (SOLID and the Law Of Demeter come to mind) so in that sense there are 'good' and 'less good' solutions. But if it makes more sense to you for the Book-class to have a Borrow-method that creates a Borrowing object on the book, there is nothing wrong with that.

Things like the Single Responsibility Principle (SRP, the S in SOLID) can help you look at the design you think will work and analyse it. For example, with my proposed design Library violates the SRP as it is responsible for creating reservations, creating lendings AND checking availabilities. By explaining the role of the Library class I can immediately see that I violate SRP and there might be a more optimal design.

Then again, if you were to apply all SOLID principles to the letter you wouldn't be able to write any code...

*Simplified for obvious reasons, in reality libraries would have multiple copies of some books etc...

JDT
  • 6,302
  • 17
  • 32
  • Thank you! However I need more details, in your explanation you assigned most of the methods to the Library class, Why not book or member, why not a new class as Borrowing... – Ahmad Mar 11 '15 at 05:10
  • I used 'Lending' instead of 'Borrowing', but the idea is the same. According to the dictionary, the library lends to the customer and the customer borrows from the library so you would want to use the term that matches the direction of the method if that sort of things matter... – JDT Mar 11 '15 at 13:28
  • I've edited my response some more to try and answer the additional questions... – JDT Mar 11 '15 at 13:40
  • As an additional detail...Sequence Diagrams are your best friend when working with Use-Cases. They will help you identify classes, missing information, necessary information and also help you decide which class gets which operations. – Dunk Mar 12 '15 at 17:41
1

The trick is to specify the behavior you want in plain language.

"A member borrows a book"

You have two nouns in that sentence. Each noun it is likely to end up as a class-- in your case Book and Member.

There is also the verb "borrows" this will likely end up as a method in one of the classes, and, most likely the subject -- its the member who is doing it so the "borrow" method should be part of the Member class.

Then we come to adjectives the member does the borrowing but a book can be "borrowed" it follows that you should somehow record the "borrowed" status in the book class maybe even who did the borrowing.

Finally in real life things are made up of other things. It may be enough for you to store the publishers name as an attribute of the Book class, but, if your library does purchasing then you will probably end up with a Publisher class, in your book class you will then need a reference to the Publisher class.

James Anderson
  • 18,049
  • 1
  • 42
  • 72
  • 1
    PS -- you could end up with a completely different (but) valid design by re-phrasing the problem. "The librarian loans the book to the member" ; now you have a librarian class with a "loan" method and two passive classes for "member" and "book". It often pays to play with the phrasing to get an insight to the problem. – James Anderson Mar 12 '15 at 08:53
  • Good point about playing with the phrasing as it can result in a much easier system. But in the end, you really want to be consistent in the phrasing and word choices across all your stories. It definitely helps make all the pieces fit together much nicer. We've found that it is really beneficial to have only one person be the "author" to make sure this happens even if many people are helping to define the stories. – Dunk Mar 12 '15 at 17:36