Здравствуйте, Артем1, Вы писали:

А>Посоветуйте, как бы вы решали такую проблему.

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

Т.е. если CostInfo и OtherCostInfo имеют общего предка CostInfoParent, то в этом классе сделать метод вроде

public void CopyTo(CostInfoParent other)
{
   // ...
}

Но у меня есть ощущение, что рано или поздно вам все равно придется преобразовывать CostInfo в OtherCostInfo и обратно, и этот путь — неправильный. Особенно печально все станет, если родственников CostInfo много, и наследники добавляют в базовый класс различные данные.

Поэтому я бы в первую очередь занялся тем, что изменил бы "другой SomeCostHolder" так, чтобы он принимал любые типы, которые ему могут прийти.
Поскольку деталей про SomeCostHolder нет, то и посоветовать что-либо трудно.

Как вариант: можно выделить код, из-за которого "другой SomeCostHolder" не может обрабатывать CostInfo, в отдельный класс. Затем также в отдельный класс с тем же интерфейсом оформить код, аналогично работающий с OtherCostInfo. Далее применить паттерн dependency injection (или strategy — кому как нравится). Весьма вероятно, что в процессе этих изменений вам придется несколько изменить и классы CostInfo с родичами, т.к., похоже, в иерархии родственников CostInfo есть проблемы (либо лишние классы, либо каких-то классов не хватает).

[skipped]

А>И тут выяснилось, что бывают ситуации, когда при копировании надо конвертировать CostInfo в OtherCostInfo, т.к. другой SomeCostHolder, в который копируются данные, не ожидает у себя в коллекции CostInfo. Проблема у меня тут в том, что метод Clone специально добавлен в DomainModel, что-бы быть поближе к копируемым данным и не забывать его обновлять при изменении модели. А теперь ситуация вынуждает превратить копирование (клонирование) в конвертирование. Для задачи достаточно скопировать только то, что может быть скопировано (от общих предков). Специальная логика конвертации не требуется. При этом не хочется вводит связность в модель (разные наследники знают друг о друге) и не хочется тащить все это вовне в отдельный класс (будем забывать обновлять его). Вводить m:m конвертеров по кол-ву возможных сочетаний как то тоже гм.
А>Свое решение приводить не буду (пока), хочется посмотреть на возможные подходы.

А>зы: а то три года времени не было толком на форуме посидеть, а тут как почитал, сколько копий сломано в Anemic vs Rich, так сразу сомнения появляются в квалификации
А>ззы: высказывания по типу SomeCostHolder криво спроектирован тоже принимаются, но с примером, как надо было спроектировать