V>>Чем обеспечивается зависимость? Впрочем, это тот же вопрос, что и предыдущий. Мои наихудшие подозрения оправдались.

Состояния может и не быть, а зависимость будет в любом случае.

I>Походу, код показать ты не в состоянии

I>Прочесть коммент болдом ты не в состоянии ? Надо было сразу сказать

>Вот есть твои методы PreDo() и PostDo(). Они требовали для своей работы каких-то внутренних полей первоначального класса Doer?
Разумеется не требовали и это элементарно.
>Если требовали, то тебе надо обеспечить доступ к этим полям в новом объекте PreAndPostDoerDecorator, ЧТД.
Во первых, не требовали. Во вторых, они могут пользоваться методами базового класса

I>в моем решении ненужно модифицировать ни генераторы, не фреймворк, вообще ничего нужно только сделать один декоратор на каждую задачу.

interface IRenderer
{
  void Render(Context ctx);
}

interface IRenderAspect 
{
  void Pre(IRenderer renderer, Context ctx);
  void Post(IRenderer renderer, Context ctx);
}

class RendererWithAspect : IRenderer
{
  IRenderAspect _aspect;
  IRenderer _renderer;

  public RendererWithAspect(IRenderAspect aspect, IRenderer renderer) 
  { 
    _aspect = aspect; 
    _renderer = renderer;
  }

  public void Render(Context ctx)
  {
    _aspect.Pre(_renderer, ctx);
    _renderer.Render(ctx);
    _aspect.Post(_renderer, ctx);
  }
}

class AspectStack : IRenderAspect
{
  IRenderAspect _top;
  IRenderAspect _next;

  public AspectStack(IRenderAspect top, IRenderAspect next)
  {
    _top = top;
    _next = next;
  }

  public void Pre(IRenderer renderer, Context ctx)
  {
    _top.Pre(renderer, ctx);
    _next.Pre(renderer, ctx);
  }

  public void Post(IRenderer renderer, Context ctx)
  {
    _next.Post(renderer, ctx);
    _top.Post(renderer, ctx);
  }
}

// тут наследуем, т.к. PreDo()/PostDo() требуют особого доступа к базе по условию,
class PreAndPostDecorator : ThirdPartyClass

ThirdPartyClass - ЭТО ЖОСТКАЯ ЗАВИСИМОСТЬ КОТОРАЯ ПРЕПЯТСТВУЕТ ТЕСТИРОВАНИЮ


{
  public void PreDo() {}
  public void PostDo() {}
}

// структурная композиция
class PreAndPostDoerDecorator : IDoer
{
  private PreAndPostDecorator _decorator = new PreAndPostDecorator();

ВОТ ЭТО ЖОСТКАЯ ЗАВИСИМОСТЬ КОТОРАЯ ПРЕПЯТСТВУЕТ ТЕСТИРОВАНИЮ

 
  PreAndPostDoerDecorator(IDoer doer){  _doer = doer;} 

  void Do() {
    _decorator.PreDo();
    _doer.Do();
    _decorator.PostDo();
  }
}

interface IDoer
{
  void Do(); 
}

// тут наследуем, т.к. PreDo()/PostDo() требуют особого доступа к базе по условию,
class PreAndPostDecorator : ThirdPartyClass
{
  public virtual void PreDo() {}  // СМОТРИМ ВНИМАТЕЛЬНО - virtual
  public virtual void PostDo() {} // СМОТРИМ ВНИМАТЕЛЬНО - virtual
}

class PreAndPostDoerDecorator : IDoer
{
  private PreAndPostDecorator _decorator;

  public PreAndPostDoerDecorator(PreAndPostDecorator d)
  {
    decorator = d;
  }

  public PreAndPostDoerDecorator(PreAndPostDecorator d)
  {
    decorator = = new PreAndPostDecorator();
  }
 
  PreAndPostDoerDecorator(IDoer doer){  _doer = doer;} 

  public void Do() {
    _decorator.PreDo();
    _doer.Do();
    _decorator.PostDo();
  }
}

interface IDoer
{
  void Do(); 
}

V>>>Чем обеспечивается зависимость? Впрочем, это тот же вопрос, что и предыдущий. Мои наихудшие подозрения оправдались.

I>>Походу, код показать ты не в состоянии

V>

someThirPartyObject.AcceptRender(widget1.Suppress()); 
someThirPartyObject.AcceptRender(widget2.Measure()); 
someThirPartyObject.AcceptRender(widget3.Log());
someThirPartyObject.AcceptRender(widget4.FixAliasing());
someThirPartyObject.AcceptRender(widget5.Deferred());

...
// вот так "аспекты" комбинируются - и без всяких одноразовых говноинтерфейсов
someThirPartyObject.AcceptRender(widget10234.Deferred().FixAliasing().Measure().Log());
...

// а теперь тем же способом рендерим всю сцену
someThirPartyObject.Log().Measure().Render(new Context());

interface IRender
{
   void Render(Context ctx);
}

// IRender реализует как мой код, так и ThirdParty, потому я не могу изменить поведение Render

// базовый для декотораторов
abstract class RenderDecoratorBase : IRender
{
  protected IRender _render;
  RenderDecoratorBase(IRender render)
  { 
      _render = render;
  }
 
  public abstract void Render(Context ctx);
}

задача 4 - маскировать рендеринг некоторых объектов

class SuppressRendrer : RenderDecoratorBase
{
  SuppressRendrer(IRender render):base(render)
  { 
  }
 
  public void Render(Context ctx) { // empty method } // :-) - этот случай тебе фантазия и не подсказала :-)
}

// вот как используется этот декоратор - точно так же, как и все другие.

someThirPartyObject.AcceptRender( new SuppressRendrer(widgetThatIsToBeHidden) );


задача 2 - логировать рендеринг некоторых объектов

class LoggingRendrer : RenderDecoratorBase
{
  LoggingRendrer(IRender render):base(render)
  { 
  }
 
  public void Render(Context ctx) 
  { 
     Log.Write("RenderBegin"); 
     
     _render.Render(ctx);
     
     Log.Write("RenderEnd");
  } // :-) 
}

someThirPartyObject.AcceptRender( new LoggingRendrer(widgetThatIsToBeLogged) );

I>>>Кто такое сказал ? Какие проблемы возникают ? Какие есть более толковые решения ? Или же вопрос чисто идеологический ?

OCaml — современный объектно-ориентированный язык

I>// тут наследуем, т.к. PreDo()/PostDo() требуют особого доступа к базе по условию,
I>class PreAndPostDecorator : ThirdPartyClass
I>ThirdPartyClass - ЭТО ЖОСТКАЯ ЗАВИСИМОСТЬ КОТОРАЯ ПРЕПЯТСТВУЕТ ТЕСТИРОВАНИЮ

1. Использование собственных интерфейсов/абстрактных классов, суть фасадов/адаптеров третьесторонних классов, вместо использования их напрямую. Одна реализация интерфейсов будет "реальная", остальные — заглушечные в целях тестирования.
2. Использование дотнетной техники CBO. Не обязательно ручками, можно брать готовые mock-фреймворки.
3. Создание целых заглушечных сборок, содержащих одноименные используемые классы в тех же неймспейсах, что замещаемые сборки. С заглушечной же реализацией лишь минимального мн-ва используемых членов. Линковка тестовой сборки с ней. Я иногда прямо тестовые исходники в проект тестовых сборок включаю, особенно если самих тестовых сборок много и много тестовых уникальных "заглушечных" сценариев. Тоже потянет.

Тебе надо было протестировать твой код, а не ThirdParty.

class ThirdParty {
  protected abstact int TemplateMethod();
  protected void EntryPoint() {}
}

interface IThirdPartyCallback {
  int TemplateMethod();
}

interface IThirdPartyAPI {
  void EntryPoint();
}

class ThirdPartyAdapter : ThirdParty, IThirdPartyAPI {
  IThirdPartyCallback _callback;

  public ThirdPartyAccess(IThirdPartyCallback callback) { _callback = callback; }
  new public void EntryPoint() { base.EntryPoint(); }
  protected override int TemplateMethod() { return _callback.TemplateMethod(); }
}

public delegate IThirdPartyAPI ThirdPartyFactory(IThirdPartyCallback callback);

class InternalParty : IThirdPartyCallback {
  IThirdPartyAPI _api;

  public InternalParty(ThirdPartyFactory factory) { _api = factory(this); }
  public void UsefulMethod() { _api.EntryPoint(); } 
  private int IThirdPartyCallback.TemplateMethod() { return 42; }
}

Я скипнул порожний текст.

    _decorator.PreDo();
    _doer.Do();
    _decorator.PostDo();