在一个抽象类中有什么理由需要一个空的具体方法吗?[英] Is there any reason for an empty concrete method in an abstract class?

本文是小编为大家收集整理的关于在一个抽象类中有什么理由需要一个空的具体方法吗?的处理/解决方法,可以参考本文帮助大家快速定位并解决问题,中文翻译不准确的可切换到English标签页查看源文。

问题描述

我最近正在查看一些开源代码picketlink代码.如果您看看此类,您会在一个摘要类中看到许多混凝土方法,这些方法无助.有什么目的吗?

我考虑了两件事:

  1. 如果该方法需要由子类覆盖而不是在父级抽象类中定义,为什么不简单地将其简单地使其抽象呢?
  2. 如果仅 实际上需要实施该方法,这不会表明需要重组类层次结构适用?

推荐答案

虽然不是最常见的情况,但有时在模板方法.在这种情况下,有一种定义流量的方法,将某些部分的具体实现留给了其子类.在某些情况下,默认的具体行为是什么都不做的,将基本方法留在基类中,但允许通过覆盖子类自定义.

hth

其他推荐答案

我个人认为这是一种代码.

就像您说的那样,除非它们具有某些基本功能 - 它们不这样做,它们应该是抽象的,强迫派生的类提供实现.

如果某些派生的类不应该为这些方法实现,那么设计可能出了点问题.

考虑一下:

public abstract class Animal
{
    public abstract string Speak();
}

public class Dog : Animal
{
    public override string Speak()
    {
        Console.WriteLine("Woof");
    }
}

public class Cat : Animal
{
    public override string Speak()
    {
        Console.WriteLine("Meow");
    }
}

到目前为止都很好,但是如果您想添加不说话的动物怎么办?

public class Ant : Animal
{
    public override string Speak()
    {
        // do nothing - ants don't speak.
    }
}

我认为这很糟糕.有人可能会这样做(您所描述的).

public abstract class Animal
{
    public string Speak()
    {
        // not abstract because not all derived animals speak.
    }
}

我认为这更好,但仍然不太好.在这种情况下,我想看到的是说话要么转移到界面,只有可以说出来的动物,或者类似的东西.

public abstract class Animal
{
}

public abstract class Mammal : Animal
{
    public abstract string Speak();
}

public class Dog : Mammal
{
    public override string Speak()
    {
        Console.WriteLine("Woof");
    }
}

public class Cat : Mammal
{
    public override string Speak()
    {
        Console.WriteLine("Meow");
    }
}

public class Ant : Animal
{
}

其他推荐答案

在安德烈斯·福特(Andres Fortier)的答案中构建,您还将在各种eventlistener适配器类中看到这种模式.例如, mouseadapter"> mouseadapter 提供相应的空的空每个侦听器方法的方法.这允许接口定义所有相关方法,但是实现以扩展相应的适配器并仅覆盖他们关心的单个方法,而不是被迫为所有其他接口方法提供空体.

本文地址:https://www.itbaoku.cn/post/627311.html

问题描述

I was recently looking through some open source code PicketLink code. If you take a look at this class, you'll see a number of concrete methods in an abstract class that do nothing. Is there any purpose whatsoever for this?

I thought about two things:

  1. If the method needs to be overriden by subclasses and not defined in the parent abstract class, why not simply make it abstract?
  2. If only some of the child classes actually need to implement the method, wouldn't this indicate the need for a restructuring of the class hierarchy so that children are not forced to have methods that are not applicable?

推荐答案

While not the most common case, sometimes it is handy in the context of a template method. In this case there is a method that defines the flow, leaving the concrete implementation of some parts to its subclasses. In some cases a default concrete behavior is to do nothing, leaving the concrete method in the base class empty, but allowing customization in the subclass by overriding it.

HTH

其他推荐答案

Personally I think it is a code smell.

Like you say, unless they have some base functionality - which they don't, they should be abstract, forcing derived classes to provide implementation.

If some derived classes shouldn't have an implementation for these methods, then there's probably something wrong with the design.

Consider this:

public abstract class Animal
{
    public abstract string Speak();
}

public class Dog : Animal
{
    public override string Speak()
    {
        Console.WriteLine("Woof");
    }
}

public class Cat : Animal
{
    public override string Speak()
    {
        Console.WriteLine("Meow");
    }
}

All fine so far, but what if you want to add an animal that doesn't speak?

public class Ant : Animal
{
    public override string Speak()
    {
        // do nothing - ants don't speak.
    }
}

This in my opinion is bad. Someone might do this (what you have described).

public abstract class Animal
{
    public string Speak()
    {
        // not abstract because not all derived animals speak.
    }
}

This in my opinion, is better, but still not great. What I would like to see in this situation is either Speak be moved to an interface and only the animals that can speak implement it, or something like this.

public abstract class Animal
{
}

public abstract class Mammal : Animal
{
    public abstract string Speak();
}

public class Dog : Mammal
{
    public override string Speak()
    {
        Console.WriteLine("Woof");
    }
}

public class Cat : Mammal
{
    public override string Speak()
    {
        Console.WriteLine("Meow");
    }
}

public class Ant : Animal
{
}

其他推荐答案

Building off of Andres Fortier's answer, you will also see this pattern a lot in Swing, with the various EventListener Adapter classes. For example, MouseAdapter provides corresponding empty methods for each listener method. This allows the interface to define all relevant methods, but implementations to extend the corresponding adapter and only override a single method they care about, instead of being forced to provide empty bodies for all other interface methods.