___>А ведь сам GoF не намного сложнее этого топика. Честно. Ну почему бы его не прочесть тем, кто не читал?

class ISomeObject {
public:
   // Не зависят от БД
   virtual bool ready() = 0;
   virtual bool beingLoaded() = 0;
   virtual SomeTimeStamp lastLoadTime() = 0;
   
   // Зависят от БД
   virtual void someIntegralData1(SomeoneData *) = 0;
   virtual void someIntegralData2(SomeoneData *) = 0;
   virtual void refresh() = 0;
protected:
   virtual ~ISomeObject(){}
};

ГВ>class ISomeObject {
ГВ>public:
ГВ>   // Не зависят от БД
ГВ>   virtual bool ready() = 0;
ГВ>   virtual bool beingLoaded() = 0;
ГВ>   virtual SomeTimeStamp lastLoadTime() = 0;
   
ГВ>   // Зависят от БД
ГВ>   virtual void someIntegralData1(SomeoneData *) = 0;
ГВ>   virtual void someIntegralData2(SomeoneData *) = 0;
ГВ>   virtual void refresh() = 0;
ГВ>protected:
ГВ>   virtual ~ISomeObject(){}
ГВ>};
ГВ>

class SomeObjectWrap
{ 
  void async_use(function<void(SomeObjectWithoutFirstThreeMethods*)> handler);
}

obj.async_use([=](SomeObjectWithoutFirstThreeMethods* obj){
  ....
});

I>>А в чем разница межде сервис локатором и IoC

DependencyA a = new DependencyA();
DependencyB b = new DependencyB();
DependencyC c = new DependencyC();
DependencyD d = new DependencyD();

Target t = new T(a,b);

t.d = d;
t.Prepare(c);

// конфигурация
locator.Register(new DependencyA());
locator.Register(new DependencyB());
locator.Register(new DependencyC());
locator.Register(new DependencyD());

//использование
Target t = new T(locator);

t.Prepare(locator.Resolve(typeof(IC)));

// реализация

ctor(Locator locator)
{
  this.a = locator.Resolve(typeof(IA));
  this.a = locator.Resolve(typeof(IB));
  this.a = locator.Resolve(typeof(IC));
  this.a = locator.Resolve(typeof(ID));
}

// конфигурация аналогична локатору, добавляется одна строка
di.ConfigureCreate(typeof(Target)).Setup((t,d) => t.Prepare(d.Resolve(typeof(IC))));

//использование
Target t = di.Resolve(typeof(Target))

// реализация и интерфейс Target может быть любой из тех, которые понятны используемому di, как правило - почти любой.

As a result I think we need a more specific name for this pattern. Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection.

I'm going to start by talking about the various forms of dependency injection, but I'll point out now that that's not the only way of removing the dependency from the application class to the plugin implementation. The other pattern you can use to do this is Service Locator, and I'll discuss that after I'm done with explaining Dependency Injection.

Проблема: Как обеспечить унифицированный интерфейс с набором разрозненных реализаций или интерфейсов, например, с подсистемой, если нежелательно высокое связывание с этой подсистемой или реализация подсистемы может измениться?
Решение: Определить одну точку взаимодействия с подсистемой — фасадный объект, обеспечивающий общий интерфейс с подсистемой и возложить на него обязанность по взаимодействию с ее компонентами. Фасад — это внешний объект, обеспечивающий единственную точку входа для служб подсистемы. Реализация других компонентов подсистемы закрыта и не видна внешним компонентам. Фасадный объект обеспечивает реализацию паттерна "Устойчивый к изменениям" с точки зрения защиты от изменений в реализации подсистемы., см. п. 3.1.9.

Проблема: Необходимо обеспечить взаимодействие несовместимых интерфейсов или как создать единый устойчивый интерфейс для нескольких компонентов с разными интерфейсами.
Решение: Конвертировать исходный интерфейс компонента к другому виду с помощью промежуточного объекта — адаптера, то есть, добавить специальный объект с общим интерфейсом в рамках данного приложения и перенаправить связи от внешних обьектов к этому объекту — адаптеру.

ГВ>>Честно говоря, я думал, что ты скажешь, что это сопоставление состояниям объекта наборов доступных методов. То есть в состоянии1 доступен набор1, в состоянии2 — набор2 и т.п. Такой себе не самый плохой метод снизить количество ошибок из-за обращения к неправильному методу.

ГВ>>Потому что в учебниках (по определению учебника) приводится иллюстрация. А превращение иллюстрации в "рекомендуемое" как раз и есть постановка лошади позади телеги.

ГВ>>Да-да... А критерии правильности растут прямо пропорционально количеству изученных приёмов. Плавали, знаем. Нет уж, программист обязан думать о времени, которое он потратит на решение задачи. Я понимаю, что это прямо противоречит устремлению к светлым идеалам, но это неотъемлемая часть инженерной работы.

___>Да вот как-то ни разу не встречал ситуации где нечего переписывать. Чаще этого _так_ много, что даже самые большие оптимисты боятся заикнуться

There is some confusion these days over the meaning of inversion of control due to the rise of IoC containers; some people confuse the general principle here with the specific styles of inversion of control (such as dependency injection) that these containers use.

Inversion of Control
When these containers talk about how they are so useful because they implement "Inversion of Control" I end up very puzzled. Inversion of control is a common characteristic of frameworks, so saying that these lightweight containers are special because they use inversion of control is like saying my car is special because it has wheels.

The question, is what aspect of control are they inverting? When I first ran into inversion of control, it was in the main control of a user interface. Early user interfaces were controlled by the application program. You would have a sequence of commands like "Enter name", "enter address"; your program would drive the prompts and pick up a response to each one. With graphical (or even screen based) UIs the UI framework would contain this main loop and your program instead provided event handlers for the various fields on the screen. The main control of the program was inverted, moved away from you to the framework.

For this new breed of containers the inversion is about how they lookup a plugin implementation. In my naive example the lister looked up the finder implementation by directly instantiating it. This stops the finder from being a plugin. The approach that these containers use is to ensure that any user of a plugin follows some convention that allows a separate assembler module to inject the implementation into the lister.

As a result I think we need a more specific name for this pattern. Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection.

The main control of the program was inverted, moved away from you to the framework.

___>For this new breed of containers the inversion is about how they lookup a plugin implementation. In my naive example the lister looked up the finder implementation by directly instantiating it. This stops the finder from being a plugin.

The approach that these containers use is to ensure that any user of a plugin follows some convention that allows a separate assembler module to inject the implementation into the lister.

___>As a result I think we need a more specific name for this pattern. Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection.

___>Ну так кто же этот незнакомец "this pattern"? Пусть он будет у каждого свой

___>Ну да ладно. Если на разногласия с SL глаза прикрыть, то собственно и спорить то не о чем. Зато IoC попиарили

some people confuse the general principle here with the specific styles of inversion of control (such as dependency injection) that these containers use.
некоторые люди путают общий принцип с конкретными стилями реализации IoC (таких как DI), что эти контейнеры используют.

These are complicated cases of inversion of control, but you run into this effect in much simpler situations. A template method is a good example: the super-class defines the flow of control, subclasses extend this overriding methods or implementing abstract methods to do the extension.

___>Но моя трактовка не содержит фантазий, домыслов и вещей, которые при помоши языка не выразить

class UnitOfWork {
public:
  virtual void commit() = 0; 
protected:
  virtual ~UnitOfWork() = 0; 
};

___>Только вот эти торопящиеся вчера почему-то обычно не любят сегодня вспоминать как это было. Так статистический результат наблюдений. Компании меняются а результат — нет

I>>Доставка депенденсов, точно так же как и с DI

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions.

Over the years, many have questioned why I use the word inversion in the name of this principle. The reason is that more traditional software development methods, such as structured analysis and design, tend to create software structures in which high-level modules depend on low-level modules and in which policy depends on detail. Indeed, one of the goals of these methods is to define the subprogram hierarchy that describes how the high-level modules make calls to the low-level modules. The initial design of the Copy program in Figure 7-1 is a good example of such a hierarchy. The dependency structure of a well-designed object-oriented program is "inverted" with respect to the dependency structure that normally results from traditional procedural methods.

...

Note that the inversion here is one of not only dependencies but also interface ownership. We often think of utility libraries as owning their own interfaces. But when DIP is applied, we find that the clients tend to own the abstract interfaces and that their servers derive from them.

This is sometimes known as the Hollywood principle: "Don't call us; we'll call you."[2] The lower-level modules provide the implementation for interfaces that are declared within, and called by, the upper-level modules.

[2] [Sweet85]

(Боб Мартин, Agile Software Development. Principles, Patterms, and Practices)

___>Если да, то забудьте про IoC. Вы его просто переросли. А вот мне еще ой как пригодится

<bean id="exampleBean" class="examples.ExampleBean">
<constructor-arg><ref bean="anotherExampleBean"/></constructor-arg>
<constructor-arg><ref bean="yetAnotherBean"/></constructor-arg>
<constructor-arg type="int"><value>1</value></constructor-arg>
</bean>

def exampleBean = new ExampleBean(anotherExampleBean, yetAnotherBean , 1);

  MegaModule module = container.Resolve<MegaModule>(CallingContext,ExecutionContext);

I>>Ага, а откуда скрипт будет брать депенденсы ?

MegaModule module = container.Resolve<MegaModule>(CallingContext,ExecutionContext);

>Почему захардкодить AST будущих прокручиваемых в динамике операций удобней, чем описать их императивно непосредственно в используемом ЯП?

I>>  MegaModule module = container.Resolve<MegaModule>(CallingContext,ExecutionContext);
I>>

Register<IClient>((ioc)=>new Client(ioc->Resolve<Scheduler>()), (c)=>SomeInitialize(c));

I>>MegaModule module = container.Resolve<MegaModule>(CallingContext,ExecutionContext);
I>>

I>>> У меня вот получается реюзать.

class TCPConnection
{
    struct StateInfo
    {
        public TCPConnection Context { get; set; }
        public bool CanOpen { get; set; }
        public bool CanClose { get; set; }
        public bool CanSend { get; set; }
    }
    public TCPConnection()
    {
        _stateMachine = new StateMachine<StateInfo>();
        var closed = _stateMachine.CreateState(new StateInfo { Context = this; CanOpen = true; });
        closed.Enter += (s, e) => { Console.WriteLine("Closed"); }
        var listen = _stateMachine.CreateState(new StateInfo { Context = this; CanClose = true; });
        _stateMachine.CreateTransition("open", closed, open);
        ... 
        _stateMachine.Start(closed);
    } 
    
    public void Open()
    {
        if (!_stateMachine.CurrentState.Info.CanOpen)
            throw new InvalidOperationException(); // либо самому отслеживать контекст
        _stateMachine.Transit("open");             // либо позволять машине кидать исключения
    }
}

I>>>И ты утверждаешь что твое решени это не State ?

I>"cами GoF не считают State" — это выдумка. State это не один паттерн, это большое семейство паттернов. А ты, похоже, взялся за старое — GoF иначе как буквально понимать отказываешься

The key idea in this pattern is to introduce an abstract class called TCPState to represent the states of the network connection

A table-based alternative. In C++ Programming Style [Car92], Cargill describes another way to impose structure on state-driven code: Heuses tables to map inputs to state transitions. For each state, atable maps every possible input to a succeeding state. In effect, this approach converts conditional code (and virtual functions, in the case of the State pattern) into a table look-up.

The key difference between table-driven state machines and the State pattern can be summed up like this: The State pattern models state-specific behavior, whereas the table-driven approach focuses ondefining state transitions.