I am building a program for a law firm.

When a staffer is active (i.e. still works at the firm) he has a password to login the program; When a staffer is inactive (i.e. no longer works at the firm) he loses his password, but his data is still registered in the database (personal information, previous job description etc.).

Since a staffer is not always a user of the program, but every user is a staffer, I thought to describe the classes like this:

class Staffer
{
    /* Fields and methods */
}
class User : Staffer
{
    string password;
}

When I update one of the objects fields, the database is also updated (using an event handler for the PropertyChanged event).

I have a screen in the program for updating an employee information, including replacing his password. This screen updates the object which represents the employee.

But which object should represent the employee? If for example, I want to update the address only, there is no reason for me to create a Users object, so I will instantiate the Staffer class. But if I want to update his password, I need to instantiate the User class to represent him. What is the best approach in an OOP perspective? Maybe I should create only a Staffer class and put the password field there with no User class?

  • c#
  • object-oriented

2

This sounds to me like you have one class (say Staffer). That staffer’s ability to use a program is an attribute (or perhaps more strictly, a relationship between a staffer and a program).

Imagine you have multiple logins/programs. How would you model that. You couldn’t do that by instantiating different users for different programs. I think it would be much more intuitive to do something like:

class Staffer {
   val allowedPrograms : Seq[Program] = ...

   def denyAccess(program : Program)
   def allowAccess(program : Program)

}

(in Scala-ish pseudo-code)

7