наскільки складним повинен бути конструктор

Я маю дискусію з колегою про те, скільки роботи може виконати конструктор. У мене є клас B, який внутрішньо вимагає іншого об'єкта A. Об'єкт A - один з небагатьох членів, якому клас B повинен виконувати свою роботу. Всі його публічні методи залежать від внутрішнього об'єкта А. Інформація про об'єкт A зберігається в БД, тому я намагаюся перевірити та отримати його, переглянувши його на БД у конструкторі. Мій колега зазначав, що конструктор не повинен робити більше роботи, крім того, щоб зафіксувати параметри конструктора. Оскільки всі публічні методи в будь-якому разі не зможуть, якщо об’єкт A не буде знайдений за допомогою входів до конструктора, я стверджував, що замість того, щоб дозволити створення екземпляра і пізніше вийти з ладу, насправді краще кинути рано в конструктор.

Що думають інші? Я використовую C #, якщо це має значення.

Читання Чи є коли-небудь причина робити всі роботи об’єкта в конструкторі? мені цікаво, що видобуток об'єкта A, перейшовши до БД, є частиною "будь-якої іншої ініціалізації, необхідної для того, щоб об'єкт був готовий до використання", тому що якби користувач передав конструкторам неправильні значення, я не зміг би використовувати жоден з його публічних методів.

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

Ваше запитання складається з двох абсолютно окремих частин:

Чи повинен я викинути виняток з конструктора, або я повинен мати метод невдачі?

Це явно застосування принципу Fail-fast . Зробити помилку конструктора набагато простіше налагодити, ніж потрібно знайти, чому метод не працює. Наприклад, ви можете отримати екземпляр, вже створений з якоїсь іншої частини коду, і ви отримаєте помилки під час виклику методів. Чи очевидно, що об’єкт створений неправильно? Ні.

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

Чи можу я отримати доступ до "інших частин системи, як БД" від конструктора.

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

Тьфу.

Конструктор повинен робити якомога менше - проблема полягає в тому, що поведінка виключень у конструкторах є незручною. Дуже мало програмістів знає, що таке правильна поведінка (включаючи сценарії успадкування), і змушувати своїх користувачів спробувати / зловити кожну інстанцію - в кращому випадку боляче.

Для цього в конструкторі та використанні конструктора є дві частини . У конструкторі це незручно, тому що ти не можеш багато зробити там, коли трапляється виняток. Ви не можете повернути інший тип. Ви не можете повернути null. Ви в основному можете повторно скинути виняток, повернути зламаний об'єкт (поганий конвектор) або (в кращому випадку) замінити якусь внутрішню частину на здоровий за замовчуванням. Використовувати конструктор незручно, тому що тоді ваші інстанції (і дані всіх похідних типів!) Можуть кинутись. Тоді ви не можете їх використовувати в ініціалізаторах членів. Ви в кінцевому підсумку використовуєте винятки для логіки, щоб побачити, "чи моє творіння вдалося?", Крім читабельності (та крихкості), спричиненої спробою / ловити всюди.

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

Баланс складності конструкції - методу справді є предметом дискусії про хороший стиль. Досить часто використовується порожній конструктор Class() {}із методом Init(..) {..}для більш складних речей. Серед аргументів, які слід враховувати:

• Можливість серіалізації класів
• Використовуючи метод відділення Init від конструктора, вам часто потрібно повторювати одну і ту ж послідовність Class x = new Class(); x.Init(..);багато разів, частково в Unit Tests. Однак не дуже добре, кришталево чисте для читання. Іноді я просто кладу їх в один рядок коду.
• Коли цільовий блок-тест - це лише тест ініціалізації класу, краще мати власний Init, виконувати складніші дії, що виконуються один за одним, з проміжними твердженнями.