Question

如果我从基类继承，是否有一条规则表明“只继承你需要实现/使用所有（或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类继承是否错误（我知道我只能继承一次，但这不是这个问题的因素）（另请注意，我故意不包括任何抽象方法/字段。

Answer 1

在我看到灯光之前，我在相当多的项目中走了这条路。＆＃34;

是否存在一条规则，表明只会继承您需要实现/使用所有（或X％）基类功能/方法的地方＆＃34;？

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

底线，如果有疑问（或者只是感觉有趣），不要使用继承。这由Liskov substitution principle体现，它指出任何子类应该是它的超类的完整和适当的替代。（即不要因为他们都可以携带人而Boat子类Plane。

要获得更有趣的阅读，请查看SOLID软件工程范例。

Answer 2

抽象类的问题是，其中包含哪些方法和属性。如果每个后代都覆盖其中的每个方法，那么这是一个很好的设计。虽然你可以像使用界面一样轻松。当您不仅要定义契约（方法签名），还要实现某些默认行为时，抽象类是更好的选择。

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

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

这回到我的实例是很好的或有一个东西。

我的经验表明，只有在定义的合同由需求修复时才应使用抽象基类。如果它有很大的潜力可以改变它的作用而不是它的作用，那就不要靠近它。

Answer 3

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

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

Answer 4

使用时实际上有一些好处，而不是使用继承。你应该先阅读这篇文章：

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

基类 - 应该实现所有方法

4 个答案: