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


CEM>Сам я обычно стараюсь ничего стороннего не брать, потому что:
CEM>минусы:
CEM>0. чужие баги, тормоза, ограниченность функционала. и всё в самый неподходящий момент. Медленная тех.поддержка.

Т.е. свои баги не так ранят душу? Обратите внимание что беря качественную билиотеку мы существенно сокращаем шанс багов , ибо протестирована на порядок лучше.

CEM>1. надо изучать возможности библиотеки. Как правило, несколько библиотек, чтобы выбрать.

Это в любом случае быстрее чем писать свое, априори.

CEM>2. надо изучать много чужого кода, примеров, чтобы понять, подходит это или нет. Писать тесты.

Не всегда , это сильно зависит от быбраной библиотеки.

CEM>3. инсталляторы, тяжёлые библиотеки, из которых используется меньше половины, несовместимость, неактуальность и так далее

Опять же зависит от библиотеки.

CEM>4. лицензии. Если это платное, то можно в любой момент ждать что-нибудь новенькое от авторов (2 раза было на моей памяти)
CEM>плюсы своего кода:

см. выше.


CEM>0. свой код быстро модифицируется под новые нужды
Странное магическое свойство кода . Да и зачем модифицировать если либа хорошая ?

CEM>1. опыт написания своих компонентов
CEM>2. опыт разработки архитектуры всяких мини-платформ

Звучит не серьезно.

CEM>ну и вообще, со временем появляется навык быстрого определения объёма работы в обоих случаях, что в разы облегчает жизнь

Проблемы с лицензией, иначе надо разрабатывать либы отдельно от работы .


CEM>Вот интересно, кто как и на основе чего в своей работе руководствуется при таком выборе?

Практической целесообразностью.

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

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

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

M>1. Функция stateless которая делает примитивные действия , реализуется через класс.
Не примитивные действия, а бизнес-логику. Опять же. Смотри выделенное.

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

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

M>Резюме, феерический бред.
Резюме: тупая критика.

Здравствуйте, <Аноним>, Вы писали:

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

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

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

Простейший и очевидный вариант

  Receipt chargeOrder(CreditCardProcessor processor, TransactionLog transactionLog, PizzaOrder order, CreditCard creditCard);

M>>1. Функция stateless которая делает примитивные действия , реализуется через класс.
А>Не примитивные действия, а бизнес-логику. Опять же. Смотри выделенное.

Издеваешься? Может лучше назвать позаковырестее, и оно поменяет смысл?

M>>2. Половина данных передается как мемберы , половина как параметры вызова. WTF ???
А>Данные как параметры вызова. Сервисы обработки данных — инжектятся.

Вот тут я рекомендую подучить классику типа "Совершенный код", и войти в контекст "stateless функция"

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

CreditCardProcessor processor, TransactionLog transactionLog если это не очевидно.


Хамство поскипано.

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

M>Простейший и очевидный вариант
M>

M>  Receipt chargeOrder(CreditCardProcessor processor, TransactionLog transactionLog, PizzaOrder order, CreditCard creditCard); 
M>

Допустим. Вопросы:
1. В каком классе этот метод будет и почему?
2. Когда этот метод будет вызываться, откуда вызывающая сторона будет брать CreditCardProcessor и TransactionLog?
3. Считаешь ли ты хорошим дизайном, что вызывающая сторона должна знать внутренюю реализацию, все внутренние зависимости метода?
4. Если появится ещё одна зависимость, например CookerNotificationService (отсылка уведомления повару при успешном заказе), как ты будешь менять код?

M>>>1. Функция stateless которая делает примитивные действия , реализуется через класс.
А>>Не примитивные действия, а бизнес-логику. Опять же. Смотри выделенное.
M>Издеваешься? Может лучше назвать позаковырестее, и оно поменяет смысл?
Как яхту назовёте, так и поплывёт.

M>>>2. Половина данных передается как мемберы , половина как параметры вызова. WTF ???
А>>Данные как параметры вызова. Сервисы обработки данных — инжектятся.
M>Вот тут я рекомендую подучить классику типа "Совершенный код", и войти в контекст "stateless функция"
А как насчёт того, что у тебя уже 4 аргумента у функции? В общем читать классику нужно не выборочно.

M>>>3. Вместо явной передачи данных, функия пользуется заведомо лишней третьей сущностью , которая якобы "облегчает" инициализацию дефолтных данных.
А>>Каких данных?
M>CreditCardProcessor processor, TransactionLog transactionLog если это не очевидно.
Это не данные.

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

M>>Простейший и очевидный вариант
M>>

M>>  Receipt chargeOrder(CreditCardProcessor processor, TransactionLog transactionLog, PizzaOrder order, CreditCard creditCard); 
M>>

.>Допустим. Вопросы:
.>1. В каком классе этот метод будет и почему?

В нормальных языках такой вопрос вообще не стоит — он не должен быть членом какого-либо класса.
А в C#/Java будет что-то типа BankUtils наполненный static методами.

.>3. Считаешь ли ты хорошим дизайном, что вызывающая сторона должна знать внутренюю реализацию, все внутренние зависимости метода?

Это не внутренние зависимости хотя бы потому, что при использовании IoC-Container'ов вызывающая сторона:
a) и так знает об этих зависимостях (она же видит конструкторы класса)
b) может подменить эти зависимости (либо используя класс напрямую, либо покрутив IoC-Container)

M>>>>1. Функция stateless которая делает примитивные действия , реализуется через класс.
А>>>Не примитивные действия, а бизнес-логику. Опять же. Смотри выделенное.
M>>Издеваешься? Может лучше назвать позаковырестее, и оно поменяет смысл?
.>Как яхту назовёте, так и поплывёт.

Всё-таки, что в stateless бизнес-логике такого особенного, что её нужно класть в class?

M>>>>3. Вместо явной передачи данных, функия пользуется заведомо лишней третьей сущностью , которая якобы "облегчает" инициализацию дефолтных данных.
А>>>Каких данных?
M>>CreditCardProcessor processor, TransactionLog transactionLog если это не очевидно.
.>Это не данные.

Это терминологический вопрос. Пусть будут тогда "дефолтные параметры".

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


Погорячился , вчера не заметил что класс реализует интерфейс BillingService и тем самым задает сигнатуру вызовов и т.д. В этом случае действительно оправданно агрегировать данные и изолировать их от интерфейса. В противном случае это создает больше проблем чем удобств.