我想在java代码中表示以下场景:
教授在办公室工作，可以带薪休假进行一些校外的学术活动。教授有一个有头衔，在一个系注册。教授可以是全职的教授、副教授或助理教授一个助理教授有最少的课程数。全职教授,副教授和助理教授都可以拿无薪离开。助理教授的无薪休假不应该持续太久
我使用继承来表示类:
class Professor {
String title;
Department department;
}
class AssociateProfessor extends Professor {
}
class AssistantProfessor extends Professor {
}
class FullProfessor extends Professor{
}
另一种方法是对教授类型使用enum，如:
enum professor {full, associate}`
我不确定哪一个是最好的方法。
在给定的场景中也有一些要求:
- 教授可以带薪休假
- 助理教授最低课程数
- 一些教授可以休无薪假
- 助理教授无薪休假不得超过3个月
我不确定如何在课堂上表示它们。但我已经在这里做了尝试:
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("...");
}
}
在上面，我不确定是否应该将带薪或无薪休假视为单独的类或接口或枚举，以及是否有更好的方法来表示行not last more than three months。有什么想法就太好了
你的叙述解释了不同类型的教授有不同的行为和属性:
-
候选人1:一个
«interface» Professor和FullProfessor、AssociateProfessor、AssistantProfessor三个类分别实现该接口。
优点:类设计完全灵活。不便:常见的行为将不得不重新实现几次(无DRI)。当教授改变类别时，没有连续性。 -
候选人2:一个类
Professor，带一个enumCategory，可以接受Full、Associate和Assistant的值。
优点:类设计简单。
不便之处:操作必须实现大量条件语句才能实现特定于类别的行为。如果某些类别的教授需要额外的属性，你会为所有人提供。更糟糕的是:添加教授的新类别非常困难，因为你需要更改原始类(没有OCP)。 候选人 - 3:
Professor类，专门用于FullProfessor、AssociateProfessor和AssistantProfessor三个类。
优点:通用行为只定义一次;每个专门化都可以重新定义某些行为并丰富基类。添加新的教授班级也很容易。
不便:如果教授的类别改变了，很难改变他的类别(尽管这在UML中不被禁止，但大多数语言都不允许)。 - 候选人4:类
Professor引用当前的State，并将依赖于状态的行为转发给状态。State的三个专门化:StateFullProfessor、StateAssociateProfessor和StateAssistantProfessor。顺便说一下，这是状态设计模式，它更喜欢组合而不是继承。优点:教授可以改变类别而不失去其身份的连续性。此外，对于教授来说不变的行为和属性，以及在他/她的职业生涯中发生变化的行为和属性之间的关注点也存在分离。
不便之处:略复杂。 - Candidate5类
Professor指向Role(或契约?)的集合。Role的三个专门化:RoleFullProfessor、RoleAssociateProfessor和RoleAssistantProfessor。对于每个行为，教授都会将该行为转发给所有角色。
优点:它可以应付A场的FullProfessor和b场的AssistantProfessor。
缺点:如果不需要的话，它可能是多余的。
当然还有其他候选设计(我至少看到两个)。现在由您来选择最适合您的需求。
在这些场景中，您可以记录一些额外的约束，例如"持续时间不超过三个月";使用图中的约束。{}