Есть несколько классов со сложной логикой внутри. Для инфраструктуры приложения должны быть доступны untyped-версии методов, для бизнес-логики желательно иметь красивую типизированную обёртку c парой свойств и методов.

Если решать в лоб (сампл взят из головы):

abstract class OptionSet
{
  public abstract object this[object key]
  {
    get;
    set;
  }
}
class SomeOptionSet: OptionSet
{
  public SomeOption1
  {
    get { return base["SomeOption1"]; }
  }
  public SomeOption2
  {
    get { return base["SomeOption2"]; }
  }
}

из typed-обёрток (SomeOptionSet) будут торчать наружу внутренности (в примере — индексер, у настоящих классов — зоопарк из методов и свойств).

Спрятать OptionSet в приватное поле не выйдет: куча кода, вызываемого из бизнес-логики, принимает OptionSet в качестве параметра.

Можно объявить внутренности как protected internal. Единственный недостаток: вся инфрастуктура должна будет жить в той же сборке, что и OptionSet. Уже сейчас не выйдет: инфраструктура расширяемая

Вариант 3 — объявить внутренности как protected, дополнительно ввести интерфейс IOptionSet и предоставить доступ к внутренностям через явную реализацию интерфейса.

Ещё идеи?

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


S>Можно объявить внутренности как protected internal. Единственный недостаток: вся инфрастуктура должна будет жить в той же сборке, что и OptionSet. Уже сейчас не выйдет: инфраструктура расширяемая

Т.е. InternalsVisibleTo не годится?

S>Ещё идеи?

Заменить наследование SomeOptionSet от OptionSet аггрегацией?

Здравствуйте, Jolly Roger, Вы писали:

JR>Т.е. InternalsVisibleTo не годится?
Неа. Там жуткий конструктор и красивая обёртка поверх.

JR>Заменить наследование SomeOptionSet от OptionSet аггрегацией?

спрятать OptionSet в приватное поле не выйдет: куча кода, вызываемого из бизнес-логики, принимает OptionSet в качестве параметра.

Не буду мучаться, остановлюсь на интерфейсах — самый что ни на есть компромисс.

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

S>

S>спрятать OptionSet в приватное поле не выйдет: куча кода, вызываемого из бизнес-логики, принимает OptionSet в качестве параметра.

S>

Это да, но мне показалось, что это как-бы противоречит требованию

Для инфраструктуры приложения должны быть доступны untyped-версии методов, для бизнес-логики желательно иметь красивую типизированную обёртку c парой свойств и методов.

То есть если оно уже принимает OptionSet, а надо сделать, чтобы публичные члены OptionSet были недоступны, то без рефакторинга никак

S>Не буду мучаться, остановлюсь на интерфейсах — самый что ни на есть компромисс.

+1
Если строгая изоляция не требуется и речь только об удобстве, то конечно, смысла заморачиваться никакого.

Здравствуйте, Jolly Roger, Вы писали:

JR>То есть если оно уже принимает OptionSet, а надо сделать, чтобы публичные члены OptionSet были недоступны, то без рефакторинга никак
Кто спорит

JR>Если строгая изоляция не требуется и речь только об удобстве, то конечно, смысла заморачиваться никакого.
+100500. Ибо нефиг расставлять себе грабли из-за любви к чрезмерным абстракциям. Достаточно вспомнить EF со спрятанными ParentId.

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

S>Есть несколько классов со сложной логикой внутри. Для инфраструктуры приложения должны быть доступны untyped-версии методов, для бизнес-логики желательно иметь красивую типизированную обёртку c парой свойств и методов.

Победил здравый разум — вернулись к агрегации классов внутрь типизированных обёрток.
На будущее, если кому-то придёт в голову такая же дурная идея: [i]немедленно выгоняй

Здравствуйте, Jolly Roger, Вы писали:

JR>Заменить наследование SomeOptionSet от OptionSet аггрегацией?
В конечном счёте ваш вариант победил
Спасибо!

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

S>Здравствуйте, Jolly Roger, Вы писали:

JR>>Заменить наследование SomeOptionSet от OptionSet аггрегацией?
S>В конечном счёте ваш вариант победил
S>Спасибо!

С первых строк темы я почему-то не сомневался в таком исходе...