Должен ли С# добавлять частичные конструкторы?

Ответ 1

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

Эта часть важна для вашего вопроса, чем кажется.

Если вы действительно хотите понять, как сочетается язык С#, вы можете сделать следующее: блог Эрика Липперта. Он работает на языке С# для Microsoft и много говорит о выборе функций с ограниченными ресурсами. Прочтите его блог на некоторое время, и вы начнете понимать, как функции превращают его в язык.

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

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

Поместите их вместе, и это просто не выигрышная функция.

Ответ 2

Я бы проголосовал "да", и я приведу конкретный пример, почему.

Многие технологии, которые испускают код с использованием генератора (например, Linq To SQL), будут/должны вызывать конструктор по умолчанию. Однако часто я также хочу делать что-то в конструкторе, например, при подключении к одному из событий данных.

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

Ответ 3

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

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

Ответ 4

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

Вместо того, чтобы иметь конструктор partical, запустите конструктор WinForms в конструкторе. В конце сгенерированного кода испускаем частичный метод и вызываем UserConstructor. Затем пользователи могут использовать это для их инициализации.

Вы можете даже делать закаленные частичные методы для удовлетворения всех сценариев (BeginUserConstructor и EndUserConstructor).

Ответ 5

Частичные методы не позволяют определять несколько частей тела функции в двух отдельных местах. Он просто позволяет подписи существовать в одном файле, а реализация необязательно существует в другом. Если тело никогда не определяется, ссылки на метод удаляются компилятором.

Как сказал Мехрдад... с конструктором, вам никогда не нужна такая функциональность, чтобы он никогда не реализовывался.

Ответ 6

Есть ряд связанных с конструкцией функций, которые я хотел бы видеть, что было бы полезно в сочетании с частичными конструкторами; Я не уверен, насколько полезными частичными конструкторами будут без них.

• Возможность указать, должны ли инициализироваться отдельные поля до или после конструктора базового класса, с функцией, которую поздние инициализированные поля могли ссылаться на базовый объект, или на любые части объекта, находящегося в стадии разработки, которые объявлены выше в тот же исходный файл.
• Возможность указать, что определенные поля должны быть инициализированы параметрами конструктора с тем же именем; объявление любого такого поля потребует, чтобы все конструкторы для класса либо содержали параметр с совпадающим именем и типом, либо цепочкой через тот, который делает.
• Возможность указать переменную, которая походит на инициализированное параметром поле, но может использоваться только в других инициализаторах поля. Например, если конструктор класса принимает параметр `Length`, который используется для сортировки массивов` x [] `,` y [] `и` z [] `, было бы полезно, если бы эти массивы могли быть построены с использованием синтаксис инициализатора поля.

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

Учитывая вышеописанные функции, я бы предпочел некие безпараметрические частичные конструкторы, которые были бы привязаны к полям или группам полей, так что поля могли указывать, что они будут записываться только в указанном частичном конструкторе (поведение даже более строгое чем readonly). Если значение поля будет инвариантным в течение всего жизненного цикла объекта класса, привязка его логики инициализации к полю сделает это намного яснее.

Ответ 7

Я проголосовал за да, потому что у меня недавно возникла проблема, когда частичные конструкторы нужны.

Однако я полностью понимаю проблему относительно того, как они будут упорядочены.

Подумав об этой проблеме в течение нескольких дней, я, наконец, остановился на решении, которое может работать достаточно хорошо для моих нужд. Это отражение, но все же лучше, чем ничего.

// File1.cs
public partial class Example
{
    public Example()
    {
        // Add code here to find & invoke methods with custom attribute "Initialize".
    }

    [AttributeUsage(AttributeTargets.Method)]
    public class InitializeAttribute : Attribute
    {
        // Whatever you want here.
    }
}

// File2.cs
partial class Example
{
    [Initialize]
    public void RandomMethod()
    {
        // This will be run automatically with a new instance of the object.
        // It just like it part of the constructor.
        // There is no limit to these. You can have lots of generated code pages.
    }
}