何时子类化，何时在对象模型中使用属性

本文关键字：何时 属性 子类 对象模型 | 更新日期: 2023-09-27 17:50:39

我正在为评估工具工作的对象模型寻找一些指导。目前有两种类型的计算

  • 同行
    • 团队

这两种评估之间的唯一区别是表单在UI中呈现给用户的方式。同行评估将显示团队中的同行，您应该根据某些标准对其进行评估，团队评估将显示根据某些标准对所有相关团队进行评估。除此之外，这两个评价是完全一样的。

在构建对象模型时，我是否应该创建一个抽象的评估对象，然后子类化Peer评估和Team评估?还是应该创建一个Evaluation对象，并使用两个属性来表示两种不同类型的评估?

将来可能会添加更多类型的求值

何时子类化，何时在对象模型中使用属性

一般来说，如果类型只是一条信息，则将其设置为字段。如果它被用来改变方法的行为，比如

public void foo() {
    if (type == PEER) {
        doSomething();
    }
    else {
        doSomethingElse();
    }
}

则表明您应该子类化，并使用多态性根据类型获得适当的行为。另一个解决方案是使用委托而不是继承，并将行为关联到类型:

public enum EvaluationType {
    PEER {
        @Override
        public void foo() {
            ...
        }
    },
    TEAM {
        @Override
        public void foo() {
            ...
        }
    };
    public abstract void foo();
}
public class Evaluation {
    private EvaluationType type;
    public void foo() {
        return this.type.foo();
    }
}

稍微考虑一下，在我看来，将此信息存储在evaluate对象本身是错误的方式。考虑一个现实世界的例子——南瓜籽。现在，我可以种下种子，也可以烤着吃种子。事实上，对于一个给定的种子，我可以选择一种方式，也可以选择另一种方式，但不能两者兼而有之:有些种子可以吃，有些种子可以种，但这种划分与种子本身没有什么关系。

因此，我建议在其他地方编码区别…也许您有一个EvaluationModel，它维护单独的集合(团队与同伴)，并将它们适当地转发给UI。为什么评估人员要关心其他人如何使用它?你需要的是一个以关心为职责的实体，让那个家伙想怎么区分就怎么区分吧。

拿出一个接口的常用属性和方法然后让团队和同伴自己的接口实现iccommon…

interface ICommon{
}
interface ITeam:ICommon{
}
interface IPeer:ICommon{
}

，然后实现每个接口(IPeer和ITeam)，并且您的EvaluationManager(如果您有一个)将知道何时实例化每个对象

相关文章：