c# - 我应该多积极地进行子类化以保持 DRY?

标签 c# oop inheritance interface

<分区>

这个问题是在我收到 answer was proposed to another question I asked 时想到的.假设我有一个基类

public abstract class BaseClass {}

具有相当数量的派生类 - 比方说超过六个。这些派生类中的大多数除了从基类继承的内容外没有任何相似之处,但是其中两个有这样的相似之处

public class OneOfMyDerivedClasses : BaseClass
{
    public string SimilarProperty {get; set;}
    //Other implementation details
}

public class AnotherOneOfMyDerivedClasses : BaseClass
{
    public string SimilarProperty {get; set;}
    //Other implementation details, dissimilar to those in OneOfMyDerivedClasses
}

就是这样。除了从 BaseClass 继承的内容之外,这是任何子类共享的唯一相似之处。在我的实际应用程序中,我使用定义单个 SimilarProperty 属性的接口(interface) IHaveSimilarProperty 解决了这个问题,因为我所关心的是一个对象在使用中实现了所述接口(interface)。但是因为我有重复,我是否应该为这两个派生类定义一个中间基类来继承,即

public abstract IntermediateBaseClass : BaseClass
{
    public string SimilarProperty {get; set;}
}

我也可以结合这两种方法,用接口(interface)装饰中间类......

所以我的问题是,就 OOP 最佳实践而言,这是否足以保证中间基类的重复。我应该积极消除所有重复,还是应该采取更务实的方法?如果是后者,促使我选择一种方法而不是另一种方法的经验法则是什么?

最佳答案

任何设计模式都可以走极端。以下是我在决定是否子类化时会使用的一些一般准则:

  • 代码量是否比较大(>10行)?
  • 代码是否需要定期更改(例如业务规则)
  • 我是否需要使用多态性(使用类或接口(interface)而不是其中一个子类是否有意义)

在您的情况下,由于唯一的相似之处似乎是两个类中具有相同名称 的属性,因此子类化可能不值得。

关于c# - 我应该多积极地进行子类化以保持 DRY?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/20546272/

相关文章:

javascript - 存储对象列表的正确方法

c++ - 什么没有继承到 C++ 派生类?显然, operator= 和一些构造函数实际上是继承的

c# - 这个 WPF 错误处理是个好主意吗?

c# - BeginInvoke 和 Thread.Start 之间的区别

c# - 为 Silverlight 和非 Silverlight 创建单个 DLL

c# - 将数组拆分为二维或两个数组

java - 多态性,如何避免类型转换?

c++ - 如何让子类在 C++ 中返回一个不太通用的 typedef?

java - 从基类调用重新定义的方法?

php - 组成与继承。我的数据库交互库应该使用什么?