Да, вам нужно будет реализовать конструкторы, которые имеют смысл для каждого производного, а затем использовать ключевое слово base, чтобы направить этот конструктор в соответствующий базовый класс, или ключевое слово this, чтобы направить конструктор к другому конструктору в том же классе.

Если бы компилятор сделал предположения о наследовании конструкторов, мы не смогли бы правильно определить, как были созданы наши объекты. По большей части вы должны подумать, почему у вас так много конструкторов, и подумать о том, чтобы сократить их до одного или двух в базовом классе. Затем производные классы могут маскировать некоторые из них, используя постоянные значения, такие как null, и отображать только необходимые через свои конструкторы.

Обновлять

В C# 4 вы можете указать значения параметров по умолчанию и использовать именованные параметры, чтобы один конструктор поддерживал несколько конфигураций аргументов, вместо того, чтобы иметь один конструктор для каждой конфигурации.

Да, вам нужно скопировать все 387 конструкторов. Вы можете использовать их повторно, перенаправив их:

  public Bar(int i): base(i) {}
  public Bar(int i, int j) : base(i, j) {}

но это лучшее, что вы можете сделать.

387 конструкторов ?? Это твоя главная проблема. Как насчет этого вместо этого?

public Foo(params int[] list) {...}

Слишком много конструкторов - признак поломки конструкции. Лучше класс с несколькими конструкторами и возможностью задавать свойства. Если вам действительно нужен контроль над свойствами, рассмотрите возможность создания фабрики в том же пространстве имен и сделайте установщики свойств внутренними. Позвольте фабрике решить, как создать экземпляр класса и установить его свойства. Фабрика может иметь методы, принимающие столько параметров, сколько необходимо для правильной настройки объекта.

Проблема не в том, что Bar и Bah должны копировать 387 конструкторов, проблема в том, что у Foo 387 конструкторов. Foo явно делает слишком много вещей - быстро рефакторинг! Кроме того, если у вас нет действительно веской причины для установки значений в конструкторе (что, если вы предоставляете конструктор без параметров, вы, вероятно, этого не сделаете), я бы рекомендовал использовать получение / настройку свойства.

Нет, вам не нужно копировать все 387 конструкторов в Bar и Bah. Bar и Bah могут иметь столько конструкторов, сколько вы хотите, независимо от того, сколько вы определяете в Foo. Например, вы можете выбрать только один конструктор Bar, который создает Foo с 212-м конструктором Foo.

Да, любые конструкторы, которые вы изменяете в Foo, от которых зависят Bar или Bah, потребуют от вас соответственно изменить Bar и Bah.

Нет, в .NET нет возможности наследовать конструкторы. Но вы можете добиться повторного использования кода, вызвав конструктор базового класса внутри конструктора подкласса или вызвав виртуальный метод, который вы определяете (например, Initialize ()).

Вы можете адаптировать версию Идиома виртуального конструктора C++. Насколько мне известно, C# не поддерживает ковариантные возвращаемые типы. Я считаю, что это в списках желаний многих людей.

Не забывайте, что вы также можете перенаправить конструкторы на другие конструкторы на том же уровне наследования:

public Bar(int i, int j) : this(i) { ... }
                            ^^^^^

Поскольку Foo - это класс, нельзя ли создавать виртуальные перегруженные методы Initialise()? Тогда они будут доступны для подклассов и по-прежнему могут быть расширены?

public class Foo
{
   ...
   public Foo() {...}

   public virtual void Initialise(int i) {...}
   public virtual void Initialise(int i, int i) {...}
   public virtual void Initialise(int i, int i, int i) {...}
   ... 
   public virtual void Initialise(int i, int i, ..., int i) {...}

   ...

   public virtual void SomethingElse() {...}
   ...
}

Это не должно иметь более высоких затрат на производительность, если у вас нет большого количества значений свойств по умолчанию, и вы сильно их не используете.

Жаль, что мы вынуждены сказать компилятору очевидное:

Subclass(): base() {}
Subclass(int x): base(x) {}
Subclass(int x,y): base(x,y) {}

Мне нужно сделать только 3 конструктора в 12 подклассах, так что это не проблема, но я не слишком люблю повторять это на каждом подклассе, после того, как привык не писать его так долго. Я уверен, что для этого есть веская причина, но я не думаю, что когда-либо сталкивался с проблемой, требующей такого ограничения.

public class BaseClass
{
    public BaseClass(params int[] parameters)
    {

    }   
}

public class ChildClass : BaseClass
{
    public ChildClass(params int[] parameters)
        : base(parameters)
    {

    }
}

Лично я считаю, что это ошибка Microsoft, они должны были позволить программисту переопределить видимость конструкторов, методов и свойств в базовых классах, а затем сделать так, чтобы конструкторы всегда унаследовались.

Таким образом, мы просто переопределяем (с меньшей видимостью - т.е. закрытыми) конструкторы, которые нам НЕ нужны, вместо того, чтобы добавлять все конструкторы, которые нам нужны. Delphi делает это таким образом, и я скучаю по нему.

Возьмем, к примеру, если вы хотите переопределить класс System.IO.StreamWriter, вам нужно добавить все 7 конструкторов в ваш новый класс, и если вам нравится комментировать, вам нужно прокомментировать каждый из них с помощью заголовка XML. Что еще хуже, представление метаданных не помещает XML-комментарии как правильные XML-комментарии, поэтому мы должны идти построчно, копировать и вставлять их. О чем здесь думала Microsoft?

На самом деле я написал небольшую утилиту, в которую вы можете вставить код метаданных, и она преобразует его в комментарии XML, используя скрытую видимость.

Другое простое решение может заключаться в использовании структуры или простого класса данных, который содержит параметры как свойства; таким образом вы можете заранее настроить все значения и поведение по умолчанию, передав «класс параметров» в качестве единственного параметра конструктора:

public class FooParams
{
    public int Size...
    protected myCustomStruct _ReasonForLife ...
}
public class Foo
{
    private FooParams _myParams;
    public Foo(FooParams myParams)
    {
          _myParams = myParams;
    }
}

Это позволяет избежать беспорядка с несколькими конструкторами (иногда) и дает строгую типизацию, значения по умолчанию и другие преимущества, не предоставляемые массивом параметров. Это также упрощает перенос, поскольку все, что унаследовано от Foo, все еще может добраться до FooParams или даже добавить к нему по мере необходимости. Вам все равно нужно скопировать конструктор, но вам всегда (большую часть времени) только (как правило) когда-либо (по крайней мере, на данный момент) нужен один конструктор.

public class Bar : Foo
{
    public Bar(FooParams myParams) : base(myParams) {}
}

Мне больше нравятся перегруженные подходы Initailize () и Class Factory Pattern, но иногда вам просто нужен умный конструктор. Просто мысль.

Do i really have to copy all constructors from Foo into Bar and Bah? And then if i change a constructor signature in Foo, do i have to update it in Bar and Bah?

Да, если вы используете конструкторы для создания экземпляров.

Is there no way to inherit constructors?

Неа.

Is there no way to encourage code reuse?

Что ж, я не буду вдаваться в подробности, будет ли наследование конструкторов хорошим или плохим и будет ли оно способствовать повторному использованию кода, поскольку у нас их нет и мы не собираемся их получать. :-)

Но здесь, в 2014 году, с текущим C#, вы можете получить что-то очень много унаследованных от нравиться конструкторов, используя вместо этого универсальный метод create. Это может быть полезным инструментом на поясе, но вы не дотянетесь до него легкомысленно. Я обратился к нему недавно, когда столкнулся с необходимостью передать что-то в конструктор базового типа, используемого в нескольких сотнях производных классов (до недавнего времени для базы не требовалось никаких аргументов, поэтому конструктор по умолчанию был прекрасен)   - производный классы вообще не объявляли конструкторы, а получили тот, который предоставляется автоматически).

Выглядит это так:

// In Foo:
public T create<T>(int i) where: where T : Foo, new() {
    T obj = new T();
    // Do whatever you would do with `i` in `Foo(i)` here, for instance,
    // if you save it as a data member;  `obj.dataMember = i;`
    return obj;
}

Это говорит о том, что вы можете вызвать универсальную функцию create, используя параметр типа, который является любым подтипом Foo, имеющим конструктор без аргументов.

Тогда вместо Bar b new Bar(42) вы сделаете следующее:

var b = Foo.create<Bar>(42);
// or
Bar b = Foo.create<Bar>(42);
// or
var b = Bar.create<Bar>(42); // But you still need the <Bar> bit
// or
Bar b = Bar.create<Bar>(42);

Там я показал, что метод create находится непосредственно на Foo, но, конечно, он может быть в каком-то фабричном классе, если информация, которую он настраивает, может быть установлена ​​этим фабричным классом.

Для ясности: имя create не важно, это может быть makeThingy или как угодно еще.

Полный пример

using System.IO;
using System;

class Program
{
    static void Main()
    {
        Bar b1 = Foo.create<Bar>(42);
        b1.ShowDataMember("b1");

        Bar b2 = Bar.create<Bar>(43); // Just to show `Foo.create` vs. `Bar.create` doesn't matter
        b2.ShowDataMember("b2");
    }

    class Foo
    {
        public int DataMember { get; private set; }

        public static T create<T>(int i) where T: Foo, new()
        {
            T obj = new T();
            obj.DataMember = i;
            return obj;
        }
    }

    class Bar : Foo
    {
        public void ShowDataMember(string prefix)
        {
            Console.WriteLine(prefix + ".DataMember = " + this.DataMember);
        }
    }
}