在派生类中添加属性
所以我尝试编写接口而不是实现。所以我有一个工厂，它返回一个派生自 Employee 的对象。因此，这些对象可能类似于 Developer : Employee、Secretary : Employee 等。
因此，我将所有共享属性（如 FirstName、LastName、Email 等）放在基类 (Employee) 中。
我应该将特定于每种类型的所有属性放入该类型中。因此，Developer 中会有一些属性，例如 Skills、ProgrammingLanguages 等，但是除非我使用 Developer 的具体类型，否则我将无法从 Employee 对象访问这些属性。
例如，
Employee employee = new EmployeeFactory.CreateEmployee(EmployeeType.Developer);
employee.ProgrammingLanguages = "C#, Java, C++"; <-- compile error
解决这个问题的最佳方法是什么？反射...？
So I am trying to code to an interface rather than an implementation. So I have a factory that returns an object that derives from Employee. So these objects may be something like Developer : Employee, Secretary : Employee, etc.
So I put all of the shared properties like FirstName, LastName, Email, etc. in the base class (Employee).
And I should put all of the properties specific to each type in just that type. So Developer would have some properties in it like Skills, ProgrammingLanguages, etc. but then I will not be able to access these properties from the Employee object unless I use the concrete type of Developer.
e.g.
Employee employee = new EmployeeFactory.CreateEmployee(EmployeeType.Developer);
employee.ProgrammingLanguages = "C#, Java, C++"; <-- compile error
What's the best way to go about this? Reflection...?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果您要明确说明要使用什么类型的员工，为什么还要麻烦工厂呢？
相反，您可以只写：
稍后，您仍然可以将“开发人员”添加到员工列表中，即：
Why bother with a factory if you're going to be explicitly saying what type of employee to use?
Instead, you can just write:
Later, you can still add the "developer" to a list of employees, ie:
为什么不使用泛型并使用类似的东西
并这样称呼它，
这样您最终就会得到一个类型化的开发人员。
Why not use generics and have something like
And call it like
That way you would end up with a typed Developer.
在您的代码中，显然，当您尝试执行
employee.ProgrammingLanguages时，您知道employee的类型为Developer。因此，您可以直接转换为：或者更可能：
在您不知道是否可以完成此操作的上下文中，您可以使用
is或as进行测试。将事情保持在有意义的水平来处理它们。显然，谈论可能不会编程的人的编程语言是没有意义的，因此在层次结构的
开发人员级别工作就可以了。处理假期和工资的代码对于所有员工应该是相同的，或者至少通过一个可以覆盖的通用接口来工作，因此它可以在层次结构的Employee级别上工作。In your code, clearly when you try to do
employee.ProgrammingLanguagesyou know thatemployeeis of typeDeveloper. So you can just cast to that:Or more perhaps:
In contexts where you don't know if this can be done or not, you can test with
isoras.Keep things at the level they make sense to deal with them at. Clearly it doesn't make sense to talk about the programming languages of someone who might not program, so its fine to work at the
Developerlevel of the hierarchy. Code for dealing with holidays and salary should either be the same for all employees, or at least work through a common interface with the possibility of overrides, and so it would work at theEmployeelevel of the hierarchy.在我看来，至少在这种特定情况下，您不应该使用基本类型。
您正在使用特定于
Developer的内容，而不是通用Employee的内容，因此您失去了使用基本类型的好处。在这种情况下，只需创建一个新的开发人员：话虽如此，您始终可以尝试强制转换回更具体的类型：
It seems to me like, at least in this specific case, you shouldn't be using the base type.
You're working with something specific to a
Developerrather than a genericEmployeeso you lose the benefit of working with the base type. In this case, just create a new developer:That being said, you could always try a cast back to the more specific type:
在这种情况下，我建议使用最简单的解决方案。为一种员工类型创建一种方法，如下所示：
为什么要采用这种“丑陋”的解决方案？因为无论哪种方式您都需要知道客户端代码中的类型。那么为什么要让泛型/反射变得复杂呢？简单是神圣的。
In this case I would suggest using the simpliest solution. Create one method per one employee type, like this:
Why this "ugly" solution? Because you need to know the type in the client code either way. So why to complicate with generics/reflection? Simpicity is divine.