Re[26]: своё vs. сторонее
От: . Великобритания  
Дата: 31.10.13 17:37
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>В моих ответах есть подробное описание, где и как у меня применяется DI.

Видимо, я что-то пропустил. Можно ссылку на код?

I>Как то выходит, что и RealBillingService так же для красоты.

Нет, он инкапсулирует работу с заказами, в отличие от PayProcessor, который работает с платежами.

I>Вот-вот. Раз там логики нет, значит обязанности надо будет протаскивать куда попало.

Что куда протаскивать? Зачем? Мне вот ничего не надо протаскивать...
Код в студию.

I>>>3 не ясно, что за процессор такой, если не умеет обрабатывать исключения и не может правильный результат вернуть

.>>Процессор логгирует обработку платежа. BillingService обрабатывает заказы. Это совершенно разные бизнес-сущности.
I>Может и так, но судя по коду, логируется ChargeResult который спокойно может логироваться в процессоре.
Для простоты просто. Допустим пусть будет "transactionLog.logChargeResult(result, order)".

I>Не ясно, где там SRP

А где там нет SRP?

I>>>// Receipt инкапсулирует все что ему надо, раз у него куча интересных методов

.>>Ну и зря. Тащим бизнес-логику в класс данных.
I>Эту логику можно вынести в свободные методы, собственно, у меня так и сделано.
Что ты имеешь в виду? У тебя вроде статич. метод в классе Receipt.

I>>>// процессор делает логирование и минимальную обработку ошибок, возвращает внятный результат

.>>А теперь добавляем BarclaysProcessor, который должен работать в американской пиццерии, т.к. они договорились с банком на меньшую коммисию, и наслаждаемся копипастой.
I>Покажи код. Мне совсем неочевидно, почему там должна копипаста появиться.
class PaypalProcessor {
  charge(CreditCard card, Amount amount)
  {
    try{
      var result = sendHttpRequestToPaypalUrl(card, amount);
      
      transactionLog.success(result);
      
      return ToChargeResult(result, amount);
    }
    catch(xxxException ex)
    {
       transactionLog.failure(ex);
       throw; // !!!
    }  
 } 
}
class BarclayProcessor {
  charge(CreditCard card, Amount amount)
  {
    try{
      var result = makeSoapRequestToBarclay(card, amount);
      
      transactionLog.success(result);
      
      return ToChargeResult(result, amount);
    }
    catch(xxxException ex)
    {
       transactionLog.failure(ex);
       throw; // !!!
    }  
 } 
}


I>>>Итого — DI умёр, правда без мучений

.>>Ну-ну, а теперь покажи код как transactionLog попадает внутрь PayPalProcessor?
I>Это уже не важно. Я показал что приведеный пример никому не интересен
Так это и есть самое важное! Ровно это пример и показывает!
Так и говори: "Зависимость TransactionLog инжектится внутрь PayPalProcessor, но это не Dependency Injection, т.к. я в это верю, а ты еретик", что виляешь-то? Разговор на этом и закончим.

.>>Теперь новое требование, мелкое изменение. Нужно при оформлении заказа, если заказ прошел успешно, послать уведомление повару приготовить пиццу. В случае с BillingService класс поменяется так:

.>>Всё. Ещё, конечно, добавится класс CookNotificationService. Остальной существующий код останется без изменений. Тебе же придётся менять BarclayProcessor и PayPalProcessor и везде где есть "[i]CreditCardProcessor processor = ххх;

I>Смотри внимательно — в исходном примере используется CreditCardProcessor. Если его легко заменить на BarclayProcessor , то не ясно, почему это нельзя сделать в моём случае .

Там CreditCardProcessor это интерфейс, его реализация в примере PayPalProcessor. Допустим ещё существует BarclayProcessor. Этого в твоём примере нет. У тебя имплементацию подменять нельзя.

I>Покажи код, как ты собираешься всунуть нотификацию, а я покажу свой вариант. Идет ?

Так я ж показал:
  public Receipt chargeOrder(PizzaOrder order, CreditCard creditCard) {
    try {
      ChargeResult result = processor.charge(creditCard, order.getAmount());
      transactionLog.logChargeResult(result);
      if (result.wasSuccessful())
        cookNotificationService.send(order);
      return result.wasSuccessful()
          ? Receipt.forSuccessfulCharge(order.getAmount())
          : Receipt.forDeclinedCharge(result.getDeclineMessage());
     } catch (UnreachableException e) {
      transactionLog.logConnectException(e);
      return Receipt.forSystemFailure(e.getMessage());
    }
  }


.>>Кстати, раскрой плз что значит этот "xxx".

I>В вызывающем коде гарантировано есть нужная депенденси, её напрямую можно юзать
Откуда? Давай показывай, не стесняйся. В примере это есть:
 public static void main(String[] args) {
    Injector injector = Guice.createInjector(new BillingModule());
    BillingService billingService = injector.getInstance(BillingService.class);
    // это я допишу, чтобы не напрягать твоё воображение:
    CreditCard cc = askUserCreditCardDetailsFromConsole();
    PizzaOrder order = parseOrder(args);
    billingService.chargeOrder(cc, order);
  }

Вот такой command-line interface для заказа пиццы.

I>>>processor.charge и Receipt.FromOperation стоит покрыть тестами, с первым неясно, что унутре, а со вторым все просто — он будет зависеть только от входного параметра, и не надо никаких моков, классов, интерфейсов и прочего говна.

.>>Receipt вообще покрывать не надо, там максимум конструкторы/геттеры/свойства, логику туда тащить не надо. Он сам покроется при тестировании других классов.
I>Receipt != Receipt.FromOperation
Ну правильно, вначале понапиал туда логики, теперь проблемы возникли, что класс тестить теперь приходится. "- Я так делаю, и у меня болит. — Так не делай так".

I>>>Если логика процессора будет достаточно сложной, понадобятся моки, для изоляции от сети, скажем, или базы данных и тд.

.>>Так естественно понадобятся. У тебя есть сомнения?
I>Вот и покажи внятный пример, а не этот фейк что по ссылке
Давай свой пример, а то опять что-то не понравится, но не двухстрочный фреймворк для умножения двух чисел, а что-то с несколькими бизнес-сущностями. Я же не знаю что ты ожидаешь.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[27]: своё vs. сторонее
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.11.13 10:41
Оценка:
Здравствуйте, ., Вы писали:

I>>В моих ответах есть подробное описание, где и как у меня применяется DI.

.>Видимо, я что-то пропустил. Можно ссылку на код?

На код сильно вряд ли, на гитхабе его нет
http://rsdn.ru/forum/design/5334700.1
Автор: Ikemefula
Дата: 18.10.13

http://rsdn.ru/forum/design/5334226.1
Автор: Ikemefula
Дата: 17.10.13


I>>Как то выходит, что и RealBillingService так же для красоты.

.>Нет, он инкапсулирует работу с заказами, в отличие от PayProcessor, который работает с платежами.

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

I>>Вот-вот. Раз там логики нет, значит обязанности надо будет протаскивать куда попало.

.>Что куда протаскивать? Зачем? Мне вот ничего не надо протаскивать...
.>Код в студию.

Код уже есть по той самой ссылке, где мега-тест который тестирует виртуальный вызов
Receipt.forSuccessfulCharge
Receipt.forDeclinedCharge
Receipt.forSystemFailure

Как видишь, в Receipt есть и код, и депенденси на методы уже протащены куда попало.

I>>Может и так, но судя по коду, логируется ChargeResult который спокойно может логироваться в процессоре.

.>Для простоты просто. Допустим пусть будет "transactionLog.logChargeResult(result, order)".

Ты снова корректируешь исходный пример.

I>>Не ясно, где там SRP

.>А где там нет SRP?

Смотри сам — charge, логирование, которые, как ты утверждаешь, важная обязанность, обработка ошибок и конструирование результата.

.>>>Ну и зря. Тащим бизнес-логику в класс данных.

I>>Эту логику можно вынести в свободные методы, собственно, у меня так и сделано.
.>Что ты имеешь в виду? У тебя вроде статич. метод в классе Receipt.

А в исходном примере надо полагать это не так сделано ? Там целых три метода, а у меня один.

На вторую часть попозже отвечу, у меня лимит времени на одно сообщение
Re[27]: своё vs. сторонее
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.11.13 07:26
Оценка:
Здравствуйте, ., Вы писали:

I>>>>// процессор делает логирование и минимальную обработку ошибок, возвращает внятный результат

.>>>А теперь добавляем BarclaysProcessor, который должен работать в американской пиццерии, т.к. они договорились с банком на меньшую коммисию, и наслаждаемся копипастой.
I>>Покажи код. Мне совсем неочевидно, почему там должна копипаста появиться.

Скипнул код. Транспорт протаскивать в бизнес-логику это какая то новая для меня концепция. Обычно это настраивается в конфиге приложения, для какого сервиса какой транспорт использовать. Вот кстати говоря, отличный пример DI — конфигурирование транспорта, а не тот мусор, что по ссылке.

I>>Это уже не важно. Я показал что приведеный пример никому не интересен

.>Так это и есть самое важное! Ровно это пример и показывает!

Не понял, пример показывает что он "приведеный пример никому не интересен" ?

Что ты хотел сказать, я не понял.

I>>Смотри внимательно — в исходном примере используется CreditCardProcessor. Если его легко заменить на BarclayProcessor , то не ясно, почему это нельзя сделать в моём случае .

.>Там CreditCardProcessor это интерфейс, его реализация в примере PayPalProcessor. Допустим ещё существует BarclayProcessor. Этого в твоём примере нет. У тебя имплементацию подменять нельзя.

У меня используется CreditCardProcessor, если внимательно посмотришь. Имплементация подменяется точно так же как и у тебя, только не надо дополнительный класс.


I>>Покажи код, как ты собираешься всунуть нотификацию, а я покажу свой вариант. Идет ?

.>Так я ж показал:

Идею понял, пудозреваю, если такой код не в единственном числе, то правильно оформлять как транзакцию, по завершении которой и вызовется нотификация.

Эту нотификацию нужно бросать когда Ордер переходит в состояние Paid. Этого кода нет и близко, а BillingService по прежнему как то ни о чем

Т.е. будет чтото вот так

Order order = Order.FromXXX
order.StateChange += FireNotification;
...
order.State(OrderState.Paid);
...
order.AcceptChanges(); // вот здесь будет файриться нотификация.


.>>>Кстати, раскрой плз что значит этот "xxx".

I>>В вызывающем коде гарантировано есть нужная депенденси, её напрямую можно юзать
.>Откуда? Давай показывай, не стесняйся. В примере это есть:
.>
.> public static void main(String[] args) {
.>    Injector injector = Guice.createInjector(new BillingModule());
.>    CreditCardProcessor processor = injector.getInstance(CreditCardProcessor.class);

.>  }
.>

.>Вот такой command-line interface для заказа пиццы.

Я добавил, что надо. Если в вызывающем коде есть BillingService, то нет никакой проблемы получить там же и процессор конкретный.

.>Ну правильно, вначале понапиал туда логики, теперь проблемы возникли, что класс тестить теперь приходится. "- Я так делаю, и у меня болит. — Так не делай так".


Не понял. Это я, по твоему, добавил логики в виде
Receipt.forSuccessfulCharge
Receipt.forDeclinedCharge
Receipt.forSystemFailure


I>>Вот и покажи внятный пример, а не этот фейк что по ссылке

.>Давай свой пример, а то опять что-то не понравится, но не двухстрочный фреймворк для умножения двух чисел, а что-то с несколькими бизнес-сущностями. Я же не знаю что ты ожидаешь.

Ты не волнуйся, в моем коде есть все что нужно. А вот благодаря евангелистам, которые приводят код навроде того, что по ссылке, DI воспринимается как серебряная пулька, лекарство сразу от всех болезней, в том числе и будущих.
Re: своё vs. сторонее
От: Коваленко Дмитрий Россия http://www.ibprovider.com
Дата: 30.11.13 06:16
Оценка: -1 :))
Здравствуйте, CEMb, Вы писали:

CEM>по мотивам этого поста
Автор: Vzhyk
Дата: 09.10.13
отдельно

CEM>захотелось обсудить как раз идею использования сторонних библиотек и написания
CEM>на их основе своего кода.

О наболевшем?

С одной стороны — "все самому написать просто нереально". Это я еще в 99 понял.

А с другой — в последнее время (у меня) не получается украсть позаимствовать даже элементарные вещи.

Я уже не говорю о том, чтобы взять что-то чужое готовое и встроить в свой код. Без бубна и танцев. Тут со своим иногда напляшешься.

Два года назад начал писать на C#. Кругом тонны кода. Казалось бы — изобретать уже ничего не надо. А вот хрена лысого. Хорошо перед этим я внимательно прочитал Рихтера. И там (буквально в трех строчках) была прописана истина — по-человечески никто под .NET не пишет

В итоге — пришлось все изобретать с нуля. Может поэтому удалось добраться до финиша. И, глядя на код, не возникает желание переписать его.

Так что — "все сам, все сам, своими руками"

Но самое забавное — результат всей деятельности продается другим "программистам". Иногда встречаются даже без кавычек — с такими интересно работать
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[2]: своё vs. сторонее
От: QrystaL Украина  
Дата: 30.11.13 09:26
Оценка:
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>В итоге — пришлось все изобретать с нуля.
Прямо-таки всё? и ADO.NET, и ASP.NET, и впф/винформы, свои коллекции, свой IO и т.д.?

КД>Может поэтому удалось добраться до финиша.

Как же другим удается добираться, практически ничего не переписывая?
Re[3]: своё vs. сторонее
От: Коваленко Дмитрий Россия http://www.ibprovider.com
Дата: 01.12.13 15:08
Оценка:
Здравствуйте, QrystaL, Вы писали:

КД>>В итоге — пришлось все изобретать с нуля.

QL>Прямо-таки всё? и ADO.NET, и ASP.NET, и впф/винформы, свои коллекции, свой IO и т.д.?

Проект связан с заменой System.Data.OleDb на более продвинутую нормальную реализацию.

Была бы возможность — я бы исправил некоторые вещи в System.Data.Common.

КД>>Может поэтому удалось добраться до финиша.

QL>Как же другим удается добираться, практически ничего не переписывая?

До моих финишей пока добирался только я
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[13]: своё vs. сторонее
От: TK Лес кывт.рф
Дата: 10.12.13 06:26
Оценка:
Здравствуйте, Ikemefula, Вы писали:

IT>>Ну подменяй. Что требуется от меня?

I>Как аргумент в пользу DI годится или как ?

Откуда DI знает какой именно IOpenDocument нужен в данном контексте?
Скорее всего тут несколько вариантов:
Либо Resolve<IOpenDocument> выплюнет все возможные реализации IOpenDocument из разряда "выбери что больше нравится" (а дальше будут циклы и ifы).
Либо Resolve знает какой именно IOpenDocument надо выдать. Зачем тогда нужны OpenDocumentArgs и CanExecute?
Либо Resolve<IOpenDocument>() это доступ к какому-то синглтону?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[14]: своё vs. сторонее
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.12.13 07:46
Оценка:
Здравствуйте, TK, Вы писали:

IT>>>Ну подменяй. Что требуется от меня?

I>>Как аргумент в пользу DI годится или как ?

TK>Откуда DI знает какой именно IOpenDocument нужен в данном контексте?


В конфигурации DI-контейнера описывается.

TK>Скорее всего тут несколько вариантов:

TK>Либо Resolve<IOpenDocument> выплюнет все возможные реализации IOpenDocument из разряда "выбери что больше нравится" (а дальше будут циклы и ifы).

Это не нужно, в приложении только одна реализация этого интерфейса. Для других интерфейсов может быть несколько реализаций, тогда DI-контейнер получает чтото наводе подсказки или контекста.

TK>Либо Resolve знает какой именно IOpenDocument надо выдать. Зачем тогда нужны OpenDocumentArgs и CanExecute?


xxxArgs и CanExecute нужны не для DI, а для унификации интерфейсов команд. Документы можно открывать разные — форматы, версии. Еще можно открывать по разному — с переопределением некоторых значений, с запросом у юзера тех же значений, игнорируя недостающие значения и тд и тд.
CanExecute тоже не для DI, он для UI.


TK>Либо Resolve<IOpenDocument>() это доступ к какому-то синглтону?


Не нужно никаких синглтонов Еще такой момент, кое где будет вот так Resolve("IOpenDocument") Это в основном для старого кода, который конфигурируется из xml.
Re[15]: своё vs. сторонее
От: TK Лес кывт.рф
Дата: 10.12.13 09:13
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Это не нужно, в приложении только одна реализация этого интерфейса. Для других интерфейсов может быть несколько реализаций, тогда DI-контейнер получает чтото наводе подсказки или контекста.


Если реализация одна то, все можно упростить до _openDocument.Execute(args).
А передавать в контейнер подсказки или контекст это фактически прибить логику работы к реализации контейнера.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[16]: своё vs. сторонее
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.12.13 09:18
Оценка:
Здравствуйте, TK, Вы писали:

TK>Если реализация одна то, все можно упростить до _openDocument.Execute(args).

TK>А передавать в контейнер подсказки или контекст это фактически прибить логику работы к реализации контейнера.

А где мне объявлять и инициализировать эту переменную ?

Где объявлять и инициализировать еще пару сотен таких же команд ?
Re[17]: своё vs. сторонее
От: TK Лес кывт.рф
Дата: 10.12.13 10:04
Оценка:
Здравствуйте, Ikemefula, Вы писали:

TK>>Если реализация одна то, все можно упростить до _openDocument.Execute(args).

TK>>А передавать в контейнер подсказки или контекст это фактически прибить логику работы к реализации контейнера.

I>А где мне объявлять и инициализировать эту переменную ?


В конструкторе.

I>Где объявлять и инициализировать еще пару сотен таких же команд ?


Если было не лень написать сотню классов то, пару строк на вызов конструктора это не самая большая проблема.

I>В конфигурации DI-контейнера описывается.


Кстати, а DI программируется кодом или XML'ем или через "мне повезет"?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[18]: своё vs. сторонее
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.12.13 12:25
Оценка:
Здравствуйте, TK, Вы писали:

I>>А где мне объявлять и инициализировать эту переменную ?


TK>В конструкторе.


Я шота не сильно понимаю твой аргумент
Какой профит я получу, если вытащу cmd в конструктор ? Все команды, например, пересоздаются на каждый вызов, их слишком много, что бы держать в памяти, и каждая довольно много весит.
IDocument Open(OpenDocumentArgs args)
{
  var cmd = Resolve<IOpenDocument>();

  if(cmd.CanExecute(args))
     cmd.Execute(args);
}


I>>Где объявлять и инициализировать еще пару сотен таких же команд ?


TK>Если было не лень написать сотню классов то, пару строк на вызов конструктора это не самая большая проблема.


Все что мне надо — по месту вызова команды добавить одну строку с Resolve. Ты предлагаешь вытащить её в какой нибудь конструктор ? Не вижу смысла, особенно с учетом того, что команда пересоздаётся каждый раз заново на каждый вызов.

I>>В конфигурации DI-контейнера описывается.


TK>Кстати, а DI программируется кодом или XML'ем или через "мне повезет"?


Часть через XML, осталось с незапамятных времен. Часть собтсвенно кодом, в основном команды.
XML даёт некоторый профит — приложение умеет сохранять, загружать и модифицировать свою собтсвенную конфигурацию. Теоретически это можно было и через Code Dom сорганизовать или чтото навроде, но эти требования появились где то через 5 лет после того, как ядро уже устаканилось.
Re[19]: своё vs. сторонее
От: TK Лес кывт.рф
Дата: 10.12.13 13:33
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Я шота не сильно понимаю твой аргумент

I>Какой профит я получу, если вытащу cmd в конструктор ? Все команды, например, пересоздаются на каждый вызов, их слишком много, что бы держать в памяти, и каждая довольно много весит.

Если команда это некий workflow то, зачем хранить состояние в самой команде? А если состояния как такового нет то, откуда каждая команда будет много весить?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[20]: своё vs. сторонее
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.12.13 15:03
Оценка:
Здравствуйте, TK, Вы писали:

I>>Я шота не сильно понимаю твой аргумент

I>>Какой профит я получу, если вытащу cmd в конструктор ? Все команды, например, пересоздаются на каждый вызов, их слишком много, что бы держать в памяти, и каждая довольно много весит.

TK>Если команда это некий workflow то, зачем хранить состояние в самой команде? А если состояния как такового нет то, откуда каждая команда будет много весить?


Команда удерживает довольно большой контекст.
Re: своё vs. сторонее
От: Аноним  
Дата: 10.12.13 23:40
Оценка: :)
Здравствуйте, CEMb, Вы писали:

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

А потом случилось так, что меня назначили менеджером проекта, а из нашего проекта захотели сделать SDK. И тут, неожиданно для себя, я увидел, что самописность дает однозначное преимущество в виде отсутствия зависимостей от сторонних библиотек. Более того, один из будущих заказчиков (известная крупная компания) прямо сказал, что не будет использовать наш SDK, если он будет зависеть от той библиотеки, на которую мы было собирались перейти. Также я обнаружил, что с позиции менеджера все несколько по-другому выглядит, чем с позиции разработчика. В итоге железно решили никуда не переходить, а оставить самописное, благо, что все и так уже в основном было разработано.

Такие дела. Мораль можете вывести сами.
Re[2]: своё vs. сторонее
От: minorlogic Украина  
Дата: 14.12.13 18:17
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Такие дела. Мораль можете вывести сами.


"Shit happens"
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re: своё vs. сторонее
От: c-smile Канада http://terrainformatica.com
Дата: 14.12.13 18:44
Оценка:
Здравствуйте, CEMb, Вы писали:

стороннее для тебя это всегда свое для кого-то.
стороннее для кого-то может быть и что-то твое.

Т.е. те две группы проблем что ты перечислил они актуальны и для твоего и для чужого кода.

Я хочу сказать что чужой-свой не есть проблема формализуемого дизайна и общих рекомендаций. Сугубо персональное дело.
Re[2]: своё vs. сторонее
От: minorlogic Украина  
Дата: 15.12.13 11:54
Оценка:
Дай ссылку на обсуждение DI. Судя по вики и по статьям DI называют любое нормальное использование интерфейсов. Т.е. зачем вообще вводить такие "паттерны" ума не приложу.
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[15]: своё vs. сторонее
От: minorlogic Украина  
Дата: 15.12.13 12:29
Оценка:
Здравствуйте, ., Вы писали:

.>В общем вот почитай: http://code.google.com/p/google-guice/wiki/Motivation и выскажи что такого неправильного в предложенном решении c DI и как бы ты сам решал такую задачу.


Пример по ссылке вообще является феерическим звездецом.

1. Функция stateless которая делает примитивные действия , реализуется через класс.

2. Половина данных передается как мемберы , половина как параметры вызова. WTF ???

3. Вместо явной передачи данных, функия пользуется заведомо лишней третьей сущностью , которая якобы "облегчает" инициализацию дефолтных данных.

Резюме, феерический бред.
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[11]: своё vs. сторонее
От: minorlogic Украина  
Дата: 15.12.13 13:07
Оценка:
Здравствуйте, Doc, Вы писали:

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


IT>>DI &mdash; это 25-ти доллоровый термин для 5-ти центовой концепции.


Doc>Кстати, забавная статья, про то, как человек открыл для себя тот факт, что DI это передача экземпляра заданного класса внутрь его класса. Он так скоро откроет, что там еще и интерфейсы можно использовать.


Т.е. такие статьи и сущности как DI это типа попытка научить индусов програмированию ?
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.