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?

  • I am sorry if it is a stupid question, I am trying to learn. If the question is not clear enough, please comment... My English is not great but I would try to explain it better. Thanks! – Sipo May 27 '16 at 8:27
  • You're sitting plaintext passwords in the database? That is an extremely bad idea. Please do some research on salted hashes at least before proceeding. Looking into bcrypt and scrypt would also be advisable. – David Conrad May 27 '16 at 12:26

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)

  • If I understand correctly, I should create only one class with a field that represents whether or not the staffer is a user, and a field for the password, even if he is not a user? Thanks. – Sipo May 27 '16 at 9:27
  • That might be a good first step, yes. – Brian Agnew May 27 '16 at 9:28
  • And what would be the next step? :) – Sipo May 27 '16 at 9:29
  • 2
    You might not need a next step... – Brian Agnew May 27 '16 at 9:36
  • 2
    +1, but worth pointing out that this design is effectively choosing a capability model of permissioning rather than access control lists. This may be the right decision, but it's not one the OP should gloss over if he's serious about security. cl.cam.ac.uk/~rja14/Papers/SEv2-c04.pdf covers everything he might want to know about making that decision. – Ixrec May 27 '16 at 10:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.