基类 - 是否应该实现所有方法答案

【问题标题】：Base class - should all methods be implemented基类 - 是否应该实现所有方法
【发布时间】：2012-10-04 09:09:42
【问题描述】：

如果我从基类继承，是否有一条规则规定“仅在需要实现/使用所有（或 X%）基类功能/方法的地方继承”？我知道如果我继承了，那么我就继承了很多，但这并不意味着我必须全部使用它。

假设以下模式：

public abstract class Template
{   
    public void LoadCustomer()
    {
        //Load customer logic
    }
    public virtual void LoadGrid()
    {
        //Logic   
    }
    public virtual void other()
   { //logic }

    public virtual void other2()
   { //logic }

    public virtual void other3()
   { //logic }

    public string WelcomeMessage()
    {
         //perform lots of complex logic
         return "Hello and welcome";
    }
}

如果我的应用程序的一部分只想显示 WelcomeMessage()，从上面的 Template 类继承会不会是错误的（我知道我只能继承一次，但这不是这个问题的因素）（另请注意，我故意不包含任何抽象方法/字段）。

【问题讨论】：

标签： c# inheritance

【解决方案1】：

在我“看到曙光”之前，我在很多项目中都走上了这条路。

是否有规定“仅在需要实现/使用所有（或 X%）基类功能/方法的地方继承”的规则？

是和不是。不，没有规则，但是有一种方法可以做你想做的事。它称为优先组合而不是继承，这意味着您需要将每个功能块分解为单个类，然后（在您当前的子类中）创建一个实例类，然后将所需的工作委派给它。使用这种技术，您可以轻松地修改当前的超类，而不会对当前的子类产生连锁反应。

底线，当有疑问时（或者如果它只是感觉有趣）不要使用继承。 Liskov substitution principle 体现了这一点，它指出任何子类都应该是其超类的完整且适当的替代品。（即没有 Boat 子类 Plane 只是因为它们都可以载人）。

如需更多有趣的阅读，请查看SOLID 软件工程范例。

【讨论】：

是的，我也是。我认为过于强调继承是 OO 的基石。精心挑选的增强功能数量非常有限，在课堂上看起来很棒。回到现实世界中，除了少数情况外，在所有情况下都会发生变化，将您的代码库变成格式不正确的字母汤。 OO 的意大利面条代码。

【解决方案2】：

抽象类的问题在于它有哪些方法和属性。如果每个后代都覆盖其中的每个方法，那么这是一个很好的设计。尽管您可以轻松地使用界面。当您不仅要定义合约（方法签名），还要实现一些默认行为时，抽象类是更好的选择。

想想 ToString()，如果你不覆盖它，它会返回类名。

如果您发现自己向抽象类添加方法只是为了在一小部分后代中覆盖它们，那么这是错误的选择。

这是回到我的实例是东西还是有东西。

我的经验表明，抽象基类只有在它定义的契约由需求固定时才应该使用。如果它的作用与它的作用方式相比有很大的改变潜力，请不要靠近它。

【讨论】：

【解决方案3】：

这里的问题不是继承本身，而是你的模板类看起来像god object，这很糟糕。

这就是从那个类继承感觉不对的原因。

【讨论】：

即使在实现Template method pattern 的类中，方法也需要形成一个连贯的单元。在您的情况下，这些方法看起来并没有太大的关系。
那么，您会将 ASP.NET 页面生命周期的模板视为上帝对象吗？它知道 Init/Load/Pre-render/Render 等（为上帝对象 +1，我是新手，所以这对阅读很有帮助）
@DaveRook：我不得不承认，我不知道那个模板。这些方法看起来好像它们属于一起，所以这将使它不是一个上帝对象。另一方面，.NET 框架中的许多基类都非常臃肿，所以如果模板确实有资格成为上帝对象，我不会太惊讶。

【解决方案4】：

实际上有一些使用和不使用继承的优点。你应该先阅读这篇文章：

http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx

【讨论】：