我有一个需要建议的场景。我有一个应用程序，其中有两种用户学生和教师。学生和教师共享一些常见属性，如FirstName，LastName，Email，UserName，Password等。因此，我从User中派生学生和教师课程。
现在，问题在于，如果用户是学生或老师，有时我并不知道。就像实现自定义成员资格提供程序和GetUser函数时一样。 GetUser使用userName，但现在我丢失了应该返回的内容。
对于学生功能，我为教师创建了IStudent和ITeacher。但有时候我只想回复用户而不关心他是学生还是老师。但是，返回基类似乎也不是一个好主意。
更新：
我认为退回用户是一个好主意，甚至没有学生和教师课程。学生和教师只是角色，可以由StudentServices和TeacherServices管理。
答案 0 :(得分：1)
经典场景和问题的经典失控。是的，在继承限制的情况下使用继承总是很痛苦。但是当你将行为注入你的类时会产生好处。现在看来你已经决定使用User类，而不是将User作为基础和子类教师和学生。如果你让老师和学生担任角色，但是在单独的服务中处理它们，这可能是一个好主意......好吧，这让我觉得很有趣。您可能最终会在这些服务中使用重复的代码，因为它们都需要处理用户逻辑。
事实是，如果你开始通过服务层的补偿来抵御这样的困难，那就是通向贫困域模型的道路，其中逻辑从域层泄漏到gui或服务层。 教师和学生的独特之处以及逻辑/行为的不同应该在域层中表示。
你可以使用继承（也许是最好的解决方案）或者将它们作为一个角色，你实际上将角色作为一个自定义枚举 - 看看（我想）Jimmy Bogard如何用行为来扩展自定义枚举。