Which class design is better?

Question

Which class design is better and why?

public class User
{
    public String UserName;
    public String Password;
    public String FirstName;
    public String LastName;
}

public class Employee : User
{
    public String EmployeeId;
    public String EmployeeCode;
    public String DepartmentId;
}

public class Member : User
{
    public String MemberId;
    public String JoinDate;
    public String ExpiryDate;
}

OR

public class User
{
    public String UserId;
    public String UserName;
    public String Password;
    public String FirstName;
    public String LastName;
}

public class Employee
{
    public User UserInfo;
    public String EmployeeId;
    public String EmployeeCode;
    public String DepartmentId;
}

public class Member
{
    public User UserInfo;
    public String MemberId;
    public String JoinDate;
    public String ExpiryDate;
}

Answer 1

I don't like either one. What happens when someone is both a member and an employee?

Answer 2

The question is simply answered by recognising that inheritance models an "IS-A" relationship, while membership models a "HAS-A" relationship.

• An employee IS A user
• An employee HAS A userinfo

Which one is correct? This is your answer.

Answer 3

Neither one is good. Too much mutable state. You should not be able to construct an instance of a class that is in an invalid or partially initialized state.

That said, the second one is better because it favours composition over inheritance.

Answer 4

Ask yourself the following:

• Do you want to model an Employee IS a User? If so, chose inheritance.
• Do you want to model an Employee HAS a User information? If so, use composition.
• Are virtual functions involved between the User (info) and the Employee? If so, use inheritance.
• Can an Employee have multiple instances of User (info)? If so, use composition.
• Does it make sense to assign an Employee object to a User (info) object? If so, use inheritance.

In general, strive to model the reality your program simulates, under the constraints of code complexity and required efficiency.

Answer 5

The real questions are:

• What are the business rules and user stories behind a user?
• What are the business rules and user stories behind an employee?
• What are the business rules and user stories behind a member?

These can be three completely unrelated entities or not, and that will determine whether your first or second design will work, or if another completely different design is in order.

Answer 6

I don't think composition is always better than inheritance (just usually). If Employee and Member really are Users, and they are mutually exclusive, then the first design is better. Consider the scenario where you need to access the UserName of an Employee. Using the second design you would have:

myEmployee.UserInfo.UserName

which is bad (law of Demeter), so you would refactor to:

myEmployee.UserName

which requires a small method on Employee to delegate to the User object. All of which is avoided by the first design.

Answer 7

Stating your requirement/spec might help arrive at the 'best design'.
Your question is too 'subject-to-reader-interpretation' at the moment.

Answer 8

Here's a scenario you should think about:

Composition (the 2nd example) is preferable if the same User can be both an Employee and a Member. Why? Because for two instances (Employee and Member) that represent the same User, if User data changes, you don't have to update it in two places. Only the User instance contains all the User information, and only it has to be updated. Since both Employee and Member classes contain the same User instance, they will automatically both contain the updated information.

Answer 9

Nice question although to avoid distractions about right and wrong I'd consider asking for the pros and cons of each approach -- I think that's what you meant by which is better or worse and why. Anyway ....

The First Approach aka Inheritance

Pros:

• Allows polymorphic behavior.
• Is initially simple and convenient.

Cons:

• May become complex or clumsy over time if more behavior and relations are added.

The Second Approach aka Composition

Pros:

• Maps well to non-oop scenarios like relational tables, structured programing, etc
• Is straightforward (if not necessarily convenient) to incrementally extend relations and behavior.

Cons:

• No polymorphism therefore it's less convenient to use related information and behavior

Lists like these + the questions Jon Limjap mentioned will help you make decisions and get started -- then you can find what the right answers should have been ;-)