Which class design is better? [closed]

Answer 1

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 2

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 ;-)

Answer 3

You can also think of Employee as a role of the User (Person). The role of a User can change in time (user can become unemployed) or User can have multiple roles at the same time.

Inheritance is much better when there is real "is a" relation, for example Apple - Fruit. But be very careful: Circle - Ellipse is not real "is a" relation, because cirlce has less "freedom" than ellipse (circle is a state of ellipse) - see: Circle Ellipse problem.

Answer 4

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 5

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 6

Three more options:

1. Have the User class contain the supplemental information for both employees and members, with unused fields blank (the ID of a particular User would indicate whether the user was an employee, member, both, or whatever).

2. Have an User class which contains a reference to an ISupplementalInfo, where ISupplementalInfo is inherited by ISupplementalEmployeeInfo, ISupplementalMemberInfo, etc. Code which is applicable to all users could work with User class objects, and code which had a User reference could get access to a user's supplemental information, but this approach would avoid having to change User if different combinations of supplemental information are required in future.

3. As above, but have the User class contain some kind of collection of ISupplementalInfo. This approach would have the advantage of facilitating the run-time addition of properties to a user (e.g. because a Member got hired). When using the previous approach, one would have to define different classes for different combinations of properties; turning a "member" into a "member+customer" would require different code from turning an "employee" into an "employee+customer". The disadvantage of the latter approach is that it would make it harder to guard against redundant or inconsistent attributes (using something like a Dictionary<Type, ISupplementalInfo> to hold supplemental information could work, but would seem a little "bulky").

I would tend to favor the second approach, in that it allows for future expansion better than would direct inheritance. Working with a collection of objects rather than a single object might be slightly burdensome, but that approach may be better able than the others to handle changing requirements.