Как мы можем получить длинное значение больше, чем 10 ^ 20 в Java, как предложено в Алгоритмах Седжвика, 4-е издание, с. 778?
Я думаю, поскольку каждый написал для DI, позвольте мне задать несколько вопросов.
- Когда у вас есть конфигурация DI, где все фактические реализации (а не интерфейсы), которые собираются быть введенным в класс (например, службы для контроллера), почему это не какое-то жесткое кодирование?
- Что делать, если я хочу изменить объект во время выполнения? Например, моя конфигурация уже говорит, когда я создаю экземпляр MyController, вставляю FileLogger как ILogger. Но я могу захотеть ввести DatabaseLogger.
- Каждый раз, когда я хочу изменить те объекты, которые мне нужны в AClass, мне нужно теперь изучить два места - сам класс и файл конфигурации. Как это облегчает жизнь?
- Если Aproperty из AClass не вводится, сложнее ли это издеваться?
- Возвращаясь к первому вопросу. Если использование нового объекта () плохое, почему мы внедряем реализацию, а не интерфейс? Я думаю, что многие из вас говорят, что мы на самом деле вводим интерфейс, но в конфигурации вы указываете реализацию этого интерфейса .. не во время выполнения .. он жестко запрограммирован во время компиляции.
Это основано на ответе @Adam N.
Почему PersonService больше не беспокоится о GroupMembershipService? Вы только что упомянули, что у GroupMembership есть несколько вещей (объектов / свойств), от которых это зависит. Если GMService был необходим в PService, вы бы использовали его как свойство. Вы можете издеваться над этим независимо от того, вводили вы его или нет. Единственный раз, когда я хотел бы, чтобы он был введен, - это если у GMService были более конкретные дочерние классы, которые вы не знали бы до выполнения. Затем вы хотите ввести подкласс. Или если вы хотите использовать это как синглтон или прототип. Честно говоря, файл конфигурации имеет все жестко закодированные, насколько подкласс для типа (интерфейса), который он будет вводить во время компиляции.
EDIT
Хороший комментарий Хосе Мария Арранц на DI
DI увеличивает сцепление, устраняя необходимость в определении направление зависимости и написать любой код клея.
False. Направление зависимостей находится в форме XML или в виде аннотаций, ваши зависимости написаны как XML-код и аннотации. XML и аннотации Исходный код.
DI уменьшает связь, делая все ваши компоненты модульными (то есть заменяемыми) и имеет четко определенные интерфейсы друг к другу.
Ложь. Вам не нужна инфраструктура DI для создания модульного кода на основе интерфейсов.
О сменном: с очень простым архивом .properties и Class.forName вы можете определить, какие классы могут измениться. Если ANY класс вашего кода можно изменить, Java не для вас, используйте язык сценариев. Кстати: аннотации не могут быть изменены без повторной компиляции.
На мой взгляд, есть единственная причина для каркасов DI: сокращение плиты котла. Благодаря хорошо продуманной заводской системе вы можете сделать то же самое, более контролируемое и более предсказуемое, так как ваша предпочтительная структура DI, рамочная реализация кода фреймов DI (XML и аннотации также являются исходным кодом). Проблема в том, что это сокращение плиты котла просто реально в очень простых случаях (один экземпляр для каждого класса и т. Д.), Иногда в реальном мире выбор подходящего объекта обслуживания не так прост, как сопоставление класса с одноэлементным объектом.
2 ответа
Вы можете использовать BigInteger, если вы работаете с длинным. Это может быть сколько угодно
Вы также можете использовать BigDecimal при работе с числами с плавающей запятой.
long не может сохранить ваши права
-
Они могут:
float f = 10000000000000000000f; double d = 10000000000000000000d; BigInteger bigI = new BigInteger("100000000000000000000"); BigDecimal bigD = new BigDecimal("100000000000000000000"); -
Они могут 'т
byte b = 10000000000000000000; short s = 10000000000000000000; int i = 10000000000000000000; long l = 10000000000000000000L;