how to design the classes

Question

i am using LINQ to SQL, 3.5 Framework and i would like to know which is the best way to design the classes. Taking a very simple example of User table.
If i have a User table with 3 different roles of Customer, Admin, Cashier. I would say i will need to create 3 classes for each of the role. eg customers.cs...

Question:
1) Since Linq .dbml already has the User auto generated from my user table, all the properties are already predefined, do i still need to create a User.cs class to be inherited by 3 of the classes role above? This is because i cannot add any duplicate properties in the User.cs eg Public string Name {get;set;} would failed because in the .dbml already has the property call Name.

2) This question will be very basic question i think... but i find it useful if i can know the correct answer. How should i park my functionality into the correct class? eg PrintYearlyReport(), CheckStaffSalary(), ModifySale(), UpdateGovernmentTax() .... all of these functions are under the role of Admin. It will be very readable if we have admin.PrintYearlyReport(), admin.ModifySale() ... However, if we park all the admin's functionalities in the Admin.cs file, then this file would be very very huge!!! For OOP sake, we need to have classes like eg Sale.cs, Payment.cs, Invoice.cs. If we split all those functionalities into each different classes, then we will no longer have the elegant way of calling the admin.PrintYearlyReport() anymore..

Answer 1

1. You can create sub-classes of the User class, ie, Customer , Admin , and Cashier , then specify the correct class based on the user's role. Sometimes we design by creating a method like User.IsInRole or User.HasAccessTo methods that you can call to verify they can access or use certain functionality.

2. You can split the functionality into separate files but still have them in the same class by using partial classes. If you define public partial class Admin you can define the class Admin in as many separate files as you want, and all of the properties will be added together when building the project.

Answer 2

Let's keep it simple. Usually the best answer is the simplest one. Do you need to have more than one class? May be may be not. If the differences between the roles is simple one liners, than why the need to create subclasses? I usually start out with one class and as the behavior is better defined and you can clearly diferentiate the subclasses than you create them. With that said you should think about what you want your objects to look like, and by that I mean what dependencies you what to create and what functionality will be shared. Composition vs inheretance When I think of users and roles I think: user has role x, not user is role x because roles can change. Common functionality and properties should be in a base class. May be you can put your access rules in a class that lives within the user:

User{
    Name
    Role
    Rules{ }
}

So you can say

if(user123.Rules.CanPrint())
{
Print();
}

Create the rules inside the user and pass in the role(s) so the rules class can figure out what this user can do. This is how I would do it. My point is, don't get hungup on what class should go where. Define objects and behavior and let the classes define them selves. You will learn to spot when a class is getting too big and need to breake it up.

Answer 3

You can add stereotype to your class diagram and get live persistence annotations in your java code. If you use Hibernate then from your code you can get your database. No need to create an object UML model and another model for your database. This is what I do and really cool !!

It only works with Java and not with c#.