I want to represent the following scenario in java code:

A professor works in an office and can take a paid leave to carry out some scholarly activities outside of the university. A professor has a title and is enrolled in one department. A professor can be a full professor, an associate professor, or an assistant professor. An assistant professor has a minimum number of courses. Full professors, associate professors, and assistant professors can all take an unpaid leave. The unpaid leave of an assistant professor should not last more than three months.

I have used inheritance to represent the classes:

class Professor {
    String title;
    Department department;
}

class AssociateProfessor extends Professor {
}

class AssistantProfessor extends Professor {
}

class FullProfessor extends Professor{
}

An alternative would be to use an enum for professor type like:

enum professor {full, associate}` 

I am not sure which one is the best approach.
Also there are few requirements in the given scenario:

1. professor can take a paid leave
2. assistant professor has a minimum number of courses
3. some professors can take an unpaid leave
4. unpaid leave of an assistance professor should not last more than three months

I am not sure how to represent them in classes. But I have made an attempt here:

class Professor {
    String title;
    Department department;
    int paidLeaves;
}


class AssistantProfessor extends Professor {
    int numOfCourses;
    int unpaidLeaves;

    AssistantProfessor(int _numOfCourses,...) {
        if(_numOfCourses <10)
            throw new Exception("Need a minimum number of courses");
        if(unpaidLeaves >90)
            throw new Exception("...");
    }
}

In the above, I am not sure if paid or unpaid leaves should be treated as separated as a separate class or interface or enum and if there is a better way to represent the line not last more than three months. Any thoughts would be great

CodePudding user response：

Your narrative explains that there are different kind of professors with different behaviors and properties:

• Candidate 1: An «interface» Professor and three classes FullProfessor, AssociateProfessor, and AssistantProfessor each realizing (implementing) the interface.
  Advantage: total flexibility for the class design.
  Inconvenience: the common behavior would have to be re-implemented several times (no DRI). No continuity of the professor when she/he changes category.
• Candidate 2: A class Professor with an enum Category that may take the values Full, Associate, and Assistant.
  Advantage: simple class design.
  Inconvenience: operations must implement a lot of conditional statements to implement category-specific behavior. And if some category of professors need additional properties, you'll have them for all. Worse: it's very difficult to add new categories of professors since you'd need to change the original class (no OCP).
• Candidate 3: A class Professor specialized in three classes FullProfessor, AssociateProfessor, and AssistantProfessor.
  Advantage: the common behavior is defined only once; each specialization can redefine some behavior and enrich the base class. It's also easy to add new classes of professors.
  Inconvenience: it is difficult to change class of a professor if his/her category changes (although this is not forbidden in UML, most languages don't allow it).
• Candidate 4: A class Professor refers to a current State, and forwards state-dependend behaviors to the state. Three specializations of of State: StateFullProfessor, StateAssociateProfessor, and StateAssistantProfessor. This is by the way the state design pattern, which prefers composition over inheritance. Advantage: The professor may change category without loosing the continuity of his/her identity.Also there is a separation of concerns between the behaviors and properties that are invariant for a professor, and those that change during his/her carrer.
  Inconvenience: slightly more complex.
• Candidate5: A class Professor refers to a collection of Role (or contracts?). Three specializations of of Role: RoleFullProfessor, RoleAssociateProfessor, and RoleAssistantProfessor. For every behavior the Professor forwards the bahavior to all its roles.
  Advantage: It can cope with A FullProfessor on field A that is AssistantProfessor on field B.
  Inconvenience: it may be overkill if this is not needed.

There are certainly other candidate design as well (I see at least two others). Now up to you to choose what best suits your needs.

In any of these scenarios, you may document some additional constraints such as "not last more than three months" with a constraint in the diagram. THe constraint an be expressed in natureal language between {}