c# - 在没有继承的情况下向元素添加额外属性

Question

我正在考虑针对以下问题的 OOP 最佳实践:

我们有一个使用外部 API 的程序。

API 有一个类型为Element 的对象，它基本上是一个几何元素。我们的应用程序是在几何模型上运行的验证应用程序该应用程序获取这些元素的集合并对它们执行一些几何测试。

我们用我们自己的名为“ValidationElement”的类包装这个 API 元素，并将一些额外的信息保存到这个包装元素中，这些信息不能直接从 API 元素中获取，但我们的应用程序需要这些信息。

到目前为止一切顺利，但现在应用程序应该扩展并支持其他类型的模型(基本上我们可以说应用程序在不同的环境中运行)。特别针对这个环境(并且它不适用于之前的情况)，我们想保存一个额外的参数，获取它会导致性能低下。

实现它的最佳实践选项是什么？一方面，我想避免添加与程序的特定(第一)部分无关的额外参数。另一方面，我不确定我是否要使用继承并仅为这个小的附加属性拆分该对象。

public class ValidationElement
{
        public Element Element { get; set; }
        public XYZ Location {get; set;}//The extra property
}

第一个也是简单的选择是同一个类将具有附加的属性和计算方法:

public class ValidationElement
{
        public Element Element { get; set; }
        public XYZ Location {get; set;}//The extra property
        public string AdditionalProperty { get; set; }
        public void HardProcessingCalcOfAdditionalProperty()
        {
            //hard processing
            AdditionalProperty = result
        }
}

我提到的第二个选项是继承

public class SecondTypeValidationElement : ValidationElement
{
        public string AdditionalProperty { get; set; }
        public void HardProcessingCalcOfAdditionalProperty()
        {
            //hard processing
            AdditionalProperty = result
        }
}

您认为对此的最佳做法是什么？有没有其他方法或设计模式可以帮助我实现目标？

Answer 1

I would like to avoid adding extra parameters that are not relevant to a specific(the first) part of the program.

看起来这是一个标志，表明这里应该避免继承。因为这种行为很可能不适用于其他类。

这是避免创建抽象的第二个原因:

Element which is basically a geometric element

因为:

• 所有派生元素都将具有这些附加属性。
• 有很多文章展示了如何Liskov substitution principle can be violated在几何图形中

所以让我们prefer composition over inheritance .

因此，在我看来，如果我们将计算附加属性的所有繁重、紧密耦合的逻辑移动到单独的类中，那将非常好:

public class ValidationElement
{
    public string Element { get; set; }

    public SomeExtra AdditionalProperty { get; set; }
}

public class SomeExtra
{
    public string Location { get; set; }//The extra property

    public string AdditionalProperty { get; set; }

    public void HardProcessingCalcOfAdditionalProperty()
    {
        //hard processing
        AdditionalProperty = string.Empty;
    }
}

为什么我们要创建单独的类 SomeExtra 并将逻辑放在这里:

• 如果我们想编辑逻辑HardProcessingCalcOfAdditionalProperty，那么我们将只编辑一个类SomeExtra。通过这样做，我们满足了 Single Responsibility Principle SOLID 原则。
• 我们可以轻松地为 SomeExtra 创建一些基本抽象类，然后在运行时我们可以决定应该注入(inject)什么具体实现。通过这样做，我们满足了 Open Closed Principle的 SOLID原则。

更新:

我很喜欢this answer about whether inheritance or composition should be chosen :

My acid test for the above is:

• Does TypeB want to expose the complete interface (all public methods no less) of TypeA such that TypeB can be used where TypeA isexpected? Indicates Inheritance.

  • e.g. A Cessna biplane will expose the complete interface of an airplane, if not more. So that makes it fit to derive from Airplane.

• Does TypeB want only some/part of the behavior exposed by TypeA? Indicates need for Composition.

  • e.g. A Bird may need only the fly behavior of an Airplane. In this case, it makes sense to extract it out as an interface / class /both and make it a member of both classes.

Update: Just came back to my answer and it seems now that it is incomplete without a specific mention of Barbara Liskov's LiskovSubstitution Principle as a test for 'Should I be inheriting fromthis type?'