Чи розумне використання оператора явного кастингу розумним чи поганим злом?

У мене великий об’єкт:

class BigObject{
    public int Id {get;set;}
    public string FieldA {get;set;}
    // ...
    public string FieldZ {get;set;}
}

і спеціалізований об'єкт, схожий на DTO:

class SmallObject{
    public int Id {get;set;}
    public EnumType Type {get;set;}
    public string FieldC {get;set;}
    public string FieldN {get;set;}
}

Я особисто знаходжу концепцію явного введення BigObject в SmallObject - знаючи, що це одностороння операція, що втрачає дані, - дуже інтуїтивно зрозуміла та зрозуміла:

var small = (SmallObject) bigOne;
passSmallObjectToSomeone(small);

Він реалізований за допомогою явного оператора:

public static explicit operator SmallObject(BigObject big){
    return new SmallObject{
        Id = big.Id,
        FieldC = big.FieldC,
        FieldN = big.FieldN,
        EnumType = MyEnum.BigObjectSpecific
    };
}

Тепер я міг би створити SmallObjectFactoryклас із FromBigObject(BigObject big)методом, який би зробив те саме, додавав його до ін'єкцій залежностей і називав його, коли потрібно ... але мені це здається ще більш складним і непотрібним.

PS Я не впевнений, що це актуально, але буде те, OtherBigObjectщо також вдасться перетворити SmallObject, встановивши інше EnumType.

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

Це ... Не здорово. Я працював з кодом, який зробив цей розумний трюк, і це призвело до плутанини. В кінці кінців, можна було б очікувати , щоб мати можливість просто привласнити BigObjectв SmallObjectзмінну , якщо об'єкти пов'язані досить , щоб кинути їх. Однак це не працює - ви отримуєте помилки компілятора, якщо ви намагаєтесь, оскільки щодо системи типів вони не пов'язані. Також оператору кастингу м'яко неприємно робити нові предмети.

Я б рекомендував .ToSmallObject()замість цього метод. Ясніше про те, що насправді відбувається і про як багатослівне.

Хоча я бачу, для чого вам потрібно мати SmallObject, я підійшов би до проблеми по-іншому. Мій підхід до такого типу питань полягає у використанні фасаду . Його єдиною метою є інкапсуляція BigObjectта надання доступними лише певним членам. Таким чином, це новий інтерфейс у тому ж екземплярі, а не копія. Звичайно, ви також можете скопіювати копію, але рекомендую зробити це за допомогою методу, створеного для цієї мети в поєднанні з Фасадом (наприклад return new SmallObject(instance.Clone())).

Фасад має ряд інших переваг, а саме: забезпечення того, що певні розділи вашої програми можуть використовувати лише членів, доступних через ваш фасад, фактично гарантуючи, що він не може використовувати те, про що не повинен знати. На додаток до цього, він також має величезну перевагу в тому, що ви маєте більше гнучкості в зміні BigObjectмайбутнього технічного обслуговування, не надто турбуючись про те, як воно використовується у вашій програмі. Поки ви можете наслідувати стару поведінку в тій чи іншій формі, ви можете зробити SmallObjectроботу такою ж, як і раніше, без необхідності змінювати свою програму скрізь, коли BigObjectб це було використано.

Зауважте, це BigObjectне залежить від іншого, SmallObjectа навпаки (як на мою скромну думку).

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

Я б запропонував як вимогу, яка, x=(SomeType)foo;випливаючи десь пізніше y=(SomeType)foo;, коли обидва касти застосовуються до одного і того ж об'єкта, x.Equals(y)повинна завжди і назавжди бути правдивою, навіть якщо відповідний об'єкт був змінений між двома кастами. Така ситуація може бути застосована, якби, наприклад, один мав пару об'єктів різного типу, кожен з яких мав непорушну посилання на інший, і вкидання будь-якого об'єкта до іншого типу повертало б його парний екземпляр. Він також може застосовуватися для типів, які служать обгортками для об'єктів, що змінюються, за умови, що ідентичність обернених предметів є незмінною, і два обгортки одного типу будуть повідомляти про себе як рівні, якби вони упакували одну колекцію.

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

Це може бути гаразд.

Проблема у вашому прикладі полягає в тому, що ви використовуєте такі назви приклад-ish. Поміркуйте:

SomeMethod(long longNum)
{
  int num = (int)longNum;
  /* ... */

Тепер, коли ви гарно розумієте, що означає long та int , тоді як неявна передача intдо, так longі явна передача з longto intцілком зрозуміла. Також зрозуміло, як 3стає 3і це просто ще один спосіб роботи 3. Зрозуміло, як це не вдасться int.MaxValue + 1у перевіреному контексті. Навіть як це буде працювати int.MaxValue + 1в неперевіреному контексті, і це призведе до int.MinValueне найскладнішої справи.

Так само, коли ви привласнюєтесь неявно до базового типу або явно до похідного типу, це зрозуміло кожному, хто знає, як успадкування працює, що відбувається, і який результат буде (або як він може бути невдалим).

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