Object oriented design - Library management system

Question

I'm working on the class diagram for library management system and need help in defining the relationships between the following classes - person, member, librarian and account.

In my solution, I kept it as:

• Person has an Account instance
• Member and Librarian extends Person

But, when I referred to other solutions available on internet and famous interview preparing courses, it is modelled as follows:

• Account has a Person instance
• Member and Librarian extends Account

Can you please help with what advantage does the second one gives over first? What should be the correct way to go forward?

[EDIT] Adding more information around how I am modelling Person, Account, Member and Librarian:

• Person: This class is to model basic data for a person like Address, Name, Email etc.
• Account: It contains properties like Account Id, Account status (Closed/Open/Cancelled) etc
• Member: A member is identified as person who can issue/return books. It will contain data like totalCheckedOutBooks, totalFineDue etc.
• Librarian: Librarian acts as admin to manage library. It contains behaviors like blockMember(), addBookItem() etc.

Answer 1

In programming, the devil is in the details, so without more requirements and context, this is impossible to answer.

Since this is tagged design patterns, however, keep in mind what the Gang of Four have to say:

Favor object composition over class inheritance

Any tentative solution that favours inheritance is, in this light, highly suspect.

I'll question how effective interview questions like these are, but in order to be just a little useful, the interviewer shouldn't be looking for any pre-defined 'correct' answer, but rather after the thinking process of the person being interviewed.

Given the four entities person, member, librarian, and account, I would immediately question the concept of a person. It seems as though it's deliberately placed into this context to invite an inheritance-based 'solution'.

I'd reject that notion and throw away the notion of a person unless there's some clear use case for it.

If there's some data or behaviour common to both librarians and members, I'd use composition to define an entity that both of those can share. For example, if we need to know the address of both a librarian and a member, I'd define an address entity (e.g. a class) and give both librarians and members an address.

For the rest of the scenario, e.g. where an account fits it, I'd start asking questions, since it isn't clear what an account is. For example, do all members have an account? Can a member have more than one account? Do librarians have accounts? One or several? Can librarians be members, too? Can members be librarians? Do we model one or several libraries? Etc.

Answer 2

It mainly depends on the domain you are modeling.

Ask yourself the following questions: "Can an Account exist without an associated Person?" and "Can a Person exist without an associated Account?".

In your case it might be: "An Account cannot exist without an associated Person". And: "A Person might be able to exist without an Account". Though it's most easy to validate that Account has a Person field that is not null. If you try it the other way, you would have to check all Person objects, if any of them has an Account field that's matching your Account.

In case of Member and Librarian it again depends on the domain. Are those different kind of Accounts? Or different (sub)types of Person?

Answer 3

Here is some feedback.

First of all you have 4 entities:

• person,
• member,
• librarian and
• account

You could ask yourself: is Person just a generic class that has nothing to do with a library? If so, the Person entity (or class) is not going to contain an account. A Person would simply be a class with a first name, last name, and maybe other fields e.g. date of birth. You can get creative.

Now a member sounds like someone that belongs to something i.e. someone that would be a member of the library and would therefore have an account. Also a member would typically be a person. So this means:

Member extends Person.

Look up what extends means. Essentially, you're adding functionality specific to member on top of Person. In this case you'll have an Account inside Member.

Member is composed of exactly one account (and maybe other stuff)

Read more on composition / aggregation here.

Now, the librarian... This really depends on your requirements. Is a librarian a member with special rights? Does Librarian extend Member? I actually don't see it that way personally (Librarian is an employee, Member is an end-user) but that's up to your specs.

HTH