Делает замену контейнера МОК использование Фабрик

Question

Делает замену контейнера МОК использование Фабрик

Здесь вы объявляете headptr и устанавливаете его на NULL:

struct record *headptr = NULL;

Затем вы передаете его insert:

insert(headptr, data);

Итак, ptr в insert равно NULL:

void insert(struct record *ptr, int value)

Затем вы устанавливаете curptr = ptr;, поэтому curptr равно NULL. Затем происходит сбой в этой строке:

while (value >= (curptr->data)) {

Поскольку вы пытаетесь получить доступ к памяти, на которую указывает curptr, то есть NULL на тот момент.

Я предполагаю, что вы хотели выделить память для headptr перед передачей ее в insert. Или обработайте регистр указателя как NULL в insert.

9

factory inversion-of-control c#

задан Ahmad Mageed 11 October 2009 в 08:29

5 ответов

Короткий ответ да, он позволяет его. Это сообщение в блоге показывает гладкий способ выбрать реализацию во времени выполнения с помощью Виндзора. Автор, Ayende, уточняет здесь и здесь.

Я еще не попробовал это, но я ожидаю скоро.

1

ответ дан 3 November 2019 в 00:05

Я соглашаюсь с другими ответами здесь, что да, можно сделать это тот путь. Но, почему Вы не используете дженерика?

public static IStaticDataHandler CreateHandler<T>( params object[] args )
{...

куда args может быть передан в как ctor аргументы (к, например, Активатор).

1

ответ дан 3 November 2019 в 00:05

Вы не далекий курс вообще; путем я понимаю это, Вы достаточно близки.

Путем я обычно структурировал бы этот вид вещи, должен превратить Ваш класс Фабрики в Ваш контейнер МОК, просто путем разрешения UpdateHandlers, которые возвращаются, чтобы быть указанными с помощью Внедрения зависимости. Таким образом вместо того, чтобы иметь логику в Вашем коде, который указывает, что StaticDataUpdateOffice означает возвращать OfficeUpdateHandler, можно повернуть код в простое высказывание, что StaticDataUpdateOffice возвращается что (недавно указанный) m_officeUpdateHandler переменная содержит; пока Ваш Framework удостоверяется, что Вы устанавливаете значение m_officeUpdateHandler перед вызовом фабрики Вы хороши для движения. И можно изменить значение m_officeUpdateHandler к чему-либо Вы хотите во времени выполнения, когда Ваши потребности изменяются.

Это Внедрение зависимости позволяет Вам управлять Инверсией процесса Управления; у Вас может быть простая фабрика, которая возвращает Ваши обработчики, и можно абстрагировать логику, которая управляет тем, какой обработчик возвращен в другое местоположение, как соответствующий.

Примечание: мой опыт с этим видом вещи довольно сильно управляется моим (очень положительным) опытом с Spring, и так, чтобы мог окрасить мою интерпретацию Вашего вопроса (и ответ).

3

ответ дан 3 November 2019 в 00:05

Мне еще предстоит прочитать здесь какие-либо слова, которые имеют большой смысл.

IoC больше подходит для конфигурирования?

Создание динамических объектов лучше что? Дженерики? Это все не по теме.

1) IoC - не что иное, как хорошая экономия времени по сравнению с реализацией евангелия «композиция важнее специализации / наследования».

Итак, правило №1 для использования IoC заключается в том, что вам действительно надоело иметь дело с длинными конструкторами, которые следуют принципу «привязка к контракту, а не реализация».

Другими словами, это шаблон стратегии в качестве альтернативы над шаблоном шаблона по тем же причинам (инкапсулировать ...) ... НО это больше работы для создания всех дополнительных интерфейсов / абстрактных типов, и больше работы, чтобы делать это КАЖДЫЙ раз со всеми IServiceProvicerThis и IResolverThat ... Если вы не устали от утомительного выполнения контрактов кода, таких как:

IInterestingService интерес = ... вы получите экземпляр, однако ...

добавьте еще примерно три строки, подобные этой ..

затем

IAmazementService service = new AmazementService (интересно, вторая стратегия, третья и т. Д.)

Это устарело. Так что IoC никогда не является вопросом, потому что любой, кто достаточно умен, чтобы кодировать с использованием надежного дизайна, знает лучше. Все спрашивающие имеют неправильные ответы.