Почему C# допускает абстрактный класс без абстрактных членов?

Возможно, хорошим примером является общий базовый класс, который предоставляет общие свойства и, возможно, другие члены для производных классов, но не представляет конкретный объект. Например:

public abstract class Pet
{
    public string Name{get;set;}
}

public class Dog : Pet
{
    public void Bark(){ ... }
}

У всех домашних животных есть имена, но само домашнее животное — это абстрактное понятие. Экземпляром домашнего животного должна быть собака или какое-либо другое животное.

Разница здесь в том, что вместо предоставления метода, который должен быть переопределен разработчиками, базовый класс объявляет, что все домашние животные состоят как минимум из свойства Name.

Идея состоит в том, чтобы заставить разработчика наследоваться от класса, поскольку он предназначен только для обеспечения основы для предположительно более специализированной реализации. Таким образом, базовый класс, не имея абстрактных членов, может содержать только основные методы и свойства, которые можно использовать в качестве основы для расширения.

Например:

public abstract class FourLeggedAnimal
{

    public void Walk()
    {
        // most 4 legged animals walk the same (silly example, but it works)
    }

    public void Chew()
    {

    }
}

public class Dog : FourLeggedAnimal
{
    public void Bark()
    {
    }
}

public class Cat : FourLeggedAnimal
{
    public void Purr()
    {
    }
}

Я думаю, что несколько более точным представлением вашего вопроса было бы: почему C# допускает абстрактный класс с только конкретными членами?

Ответ: Нет веских причин не делать этого. Возможно, у кого-то есть какая-то организационная структура, в которой им нравится иметь класс, не поддерживающий создание экземпляров, наверху, даже если класс под ним просто наследует и ничего не добавляет. Нет веских причин не поддерживать это.

Вы сказали это - потому что вы не можете создать его экземпляр; он предназначен только для шаблона.

Это не «на самом деле конкретный класс», если вы объявляете его абстрактным. Это доступно вам в качестве выбора дизайна.

Этот выбор дизайна может быть связан с созданием сущностей, которые (с риском смешения терминологии) являются абстракциями объектов реального мира и удобочитаемостью. Вы можете захотеть объявить параметры типа Car, но не хотите, чтобы объекты объявлялись как Car — вы хотите, чтобы каждый объект типа Car создавался как Truck, Sedan, Coupe или Roadster. Тот факт, что Car не требует, чтобы наследники добавляли реализацию, не умаляет его значения как абстрактной версии своих наследников, которая сама не может быть реализована.

Абстрактное означает обеспечение абстракции поведения. Например, Автомобиль — это абстрактная форма. У него нет реального экземпляра, но мы можем сказать, что у Vehicle есть ускорение. Точнее, Ford Ikon — это транспортное средство, а Yamaha FZ — это транспортное средство. Оба они имеют ускоряющее поведение.

Если вы сейчас сделаете это в форме класса. Транспортное средство — это абстрактный класс с методом ускорения. Хотя вы можете/не можете предоставить какой-либо абстрактный метод. Но бизнес-потребность заключается в том, что Vehicle не должен создавать экземпляр. Следовательно, вы делаете его абстрактным. Два других класса — Ikon и FZ — это конкретные классы, производные от класса Vehicle. Эти два будут иметь свои собственные свойства и поведение.

Что касается использования, использование abstract в объявлении класса, но без абстрактных членов, это то же самое, что наличие класса public, но использование protected в его конструкторах. Оба заставляют класс быть производным для его создания.

Однако, что касается самодокументирующегося кода, помечая класс abstract, он информирует других о том, что этот класс никогда не предназначен для создания экземпляров сам по себе, даже если он не имеет членов virtual или abstract. В то время как защита конструкторов не делает такого утверждения.

Компилятор не мешает логике реализации, но в вашем случае я бы просто опустил abstract ?! Кстати, некоторые методы могли быть реализованы с помощью { throw Exception("must inherit"); }, и компилятор не смог различить полностью реализованные классы и функции, включая только throw.

Вот возможная причина:

Супертип слоя

Нередко все объекты слоя имеют методы, которые нежелательно дублировать в системе. Вы можете переместить все это поведение в общий супертип слоя.

-- Мартин Фаулер

Нет причин предотвращать наличие только конкретных методов в абстрактном классе — это просто менее распространено. Супертип слоя — это тот случай, когда это может иметь смысл.

Я вижу абстрактные классы, служащие двум основным целям:

• Неполный класс, который должен быть специализирован для предоставления какой-либо конкретной услуги. Здесь абстрактные члены будут необязательными. Класс будет предоставлять некоторые услуги, которые могут использовать дочерние классы, и может определять абстрактные члены, которые он использует для предоставления своих услуг, как в Шаблон метода шаблона. Этот тип абстрактного класса предназначен для создания иерархии наследования.

• Класс, предоставляющий только статические служебные методы. В этом случае абстрактные члены вообще не имеют смысла. C# поддерживает это понятие с помощью статических классов, они неявно абстрактны и запечатаны. Это также может быть достигнуто с помощью закрытого класса с частным конструктором.