Перевірка параметрів конструктора в C # - Найкращі практики

Яка найкраща практика для перевірки параметрів конструктора?

Припустимо, простий біт C #:

public class MyClass
{
    public MyClass(string text)
    {
        if (String.IsNullOrEmpty(text))
            throw new ArgumentException("Text cannot be empty");

        // continue with normal construction
    }
}

Чи допустимо було б викинути виняток?

Альтернатива, з якою я стикався, була попередня перевірка, перш ніж ініціювати:

public class CallingClass
{
    public MyClass MakeMyClass(string text)
    {
        if (String.IsNullOrEmpty(text))
        {
            MessageBox.Show("Text cannot be empty");
            return null;
        }
        else
        {
            return new MyClass(text);
        }
    }
}

Я схильний виконувати всю свою перевірку в конструкторі. Це обов’язково, тому що я майже завжди створюю незмінні об’єкти. Для вашого конкретного випадку я вважаю це прийнятним.

if (string.IsNullOrEmpty(text))
    throw new ArgumentException("message", "text");

Якщо ви використовуєте .NET 4, ви можете це зробити. Звичайно, це залежить від того, чи вважаєте ви рядок, що містить лише пробіл, недійсним.

if (string.IsNullOrWhiteSpace(text))
    throw new ArgumentException("message", "text");

Дуже багато людей стверджують, що конструктори не повинні кидати винятків. Наприклад, KyleG на цій сторінці робить саме це. Чесно кажучи, я не можу придумати причину, чому ні.

У C ++ викидання виключення з конструктора - погана ідея, оскільки це залишає вам виділену пам’ять, що містить неініціалізований об'єкт, на який ви не маєте посилання (тобто це класичне витоку пам'яті). Ось, мабуть, звідси і походить стигма - купа розробників старої школи C ++ наполовину розробили своє навчання C # і просто застосували до нього те, що вони знали з C ++. На відміну від цього, в Objective-C Apple відокремила етап розподілу від кроку ініціалізації, тому конструктори на цій мові можуть кидати винятки.

C # не може просочити пам'ять від невдалого дзвінка до конструктора. Навіть деякі класи в .NET-рамках викидають винятки у своїх конструкторах.

Викиньте виняток IFF, клас не може бути приведений у послідовний стан щодо його семантичного використання. Інакше не варто. НІКОЛИ не дозволяйте об’єкту існувати в непослідовному стані. Це включає не надання повних конструкторів (як, наприклад, порожній конструктор + ініціалізація () до того, як ваш об'єкт буде повністю побудований) ... ДОВОЛЬНО ВІДКАЖІТЬ НІ!

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

Слід зазначити, що під "конструктором" я маю на увазі те, що клієнт закликає створити об'єкт. Це так само легко може бути чимось іншим, ніж фактична конструкція, яка має назву "Конструктор". Наприклад, щось подібне в C ++ не порушило б принцип IMNSHO:

struct funky_object
{
  ...
private:
  funky_object();
  bool initialize(std::string);

  friend boost::optional<funky_object> build_funky(std::string);
};
boost::optional<funky_object> build_funky(std::string str)
{
  funky_object fo;
  if (fo.initialize(str)) return fo;
  return boost::optional<funky_object>();
}

Оскільки єдиний спосіб створити A funky_object- це виклик build_funkyпринципу ніколи не допускати існування недійсного об'єкта, залишається неушкодженим, навіть якщо власне "Конструктор" не закінчив завдання.

Це багато зайвої роботи, хоча для сумнівної вигоди (можливо, навіть втрати). Я все одно віддаю перевагу маршруту виключення.

У цьому випадку я використовував би заводський метод. В основному, встановіть, що ваш клас має лише приватні конструктори і має заводський метод, який повертає екземпляр вашого об'єкта. Якщо початкові параметри є недійсними, просто поверніть null і попросіть код виклику вирішити, що робити.

public class MyClass
{
    private MyClass(string text)
    {
        //normal construction
    }

    public static MyClass MakeMyClass(string text)
    {
        if (String.IsNullOrEmpty(text))
            return null;
        else
            return new MyClass(text);
    }
}
public class CallingClass
{
    public MyClass MakeMyClass(string text)
    {
        var cls = MyClass.MakeMyClass(text);
        if(cls == null)
             //show messagebox or throw exception
        return cls;
    }
}

Ніколи не кидайте винятків, якщо умови не є винятковими. Я думаю, що в цьому випадку порожнє значення можна легко передати. У такому випадку використання цього шаблону дозволить уникнути винятків та покарань за ефективність, які вони несуть, зберігаючи стан MyClass дійсним.

• Конструктор не повинен мати ніяких побічних ефектів.
  • Більше, ніж ініціалізація приватного поля, слід розглядати як побічний ефект.
  • Конструктор із побічними ефектами порушує принцип одиночної відповідальності (SRP) і суперечить духу об'єктно-орієнтованого програмування (ООП).
• Конструктор повинен бути легким і ніколи не повинен виходити з ладу.
  • Наприклад, я завжди здригаюся, коли бачу блок-спроб всередині конструктора. Конструктор не повинен викидати винятки або помилки журналу.

Можна з розумом поставити під сумнів ці вказівки і сказати: "Але я не дотримуюся цих правил, і мій код працює нормально!" На це я відповів би: "Ну, це може бути правдою, поки цього не буде".

• Винятки та помилки всередині конструктора дуже несподівані. Якщо їм не скажуть, майбутні програмісти не будуть схильні оточувати ці виклики конструктора оборонним кодом.
• Якщо щось не вдасться у виробництві, генерований слід стека може бути важко проаналізувати. Верхня частина сліду стека може вказувати на виклик конструктора, але в конструкторі відбувається багато речей, і це може не вказувати на фактичну помилку LOC.
  • Я проаналізував багато слідів стеку .NET, де це було так.

Це залежить від того, чим займається MyClass. Якщо MyClass насправді був класом сховища даних, а текст параметра був рядком з'єднання, то найкращою практикою було б кинути ArgumentException. Однак якщо MyClass - це клас StringBuilder (наприклад), то ви можете просто залишити його порожнім.

Отже, це залежить від того, наскільки важливим є текст параметру методу - чи має об'єкт сенс з нульовим чи порожнім значенням?

Моя перевага - встановити за замовчуванням, але я знаю, що у Java є бібліотека "Apache Commons", яка робить щось подібне, і я думаю, що це досить непогана ідея. Я не бачу проблеми з викидом винятку, якщо неправильне значення поставило б об'єкт у непридатний стан; рядок - це не гарний приклад, але що робити, якщо це було для бідного чоловіка? Ви не можете працювати, якщо значенняnull замість ICustomerRepositoryінтерфейсу , скажімо, було передано . У такій ситуації, я б сказав, що викидання виключень - це правильний спосіб поводження з речами.

Коли я працював у c ++, я не використовував, щоб кидати винятки в конструкторі через проблему витоку пам'яті, до якої це може призвести, я навчився цьому важко. Кожен, хто працює з c ++, знає, наскільки важким і проблемним може бути витік пам'яті.

Але якщо ви перебуваєте в c # / Java, то у вас немає такої проблеми, оскільки сміттєзбірник збиратиме пам'ять. Якщо ви використовуєте C #, я думаю, що краще використовувати властивість для приємного та послідовного способу, щоб гарантувати обмеження даних.

public class MyClass
{
    private string _text;
    public string Text 
    {
        get
        {
            return _text;
        } 
        set
        {
            if (string.IsNullOrWhiteSpace(value))
                throw new ArgumentException("Text cannot be empty");
            _text = value;
        } 
    }

    public MyClass(string text)
    {
        Text = text;
        // continue with normal construction
    }
}

Закидання винятку буде справжнім болем для користувачів вашого класу. Якщо валідація - це проблема, то я, як правило, створюю об'єкт двоступеневим процесом.

1 - Створіть екземпляр

2 - Виклик методу ініціалізації з результатом повернення.

АБО

Викличте метод / функцію, яка створює для вас клас, який може зробити перевірку.

АБО

Майте прапор isValid, який мені особливо не подобається, але деякі люди це роблять.