2017-07-09 10:10:51

• Начинаю чувствовать двойственность фреймворка. Только хорошо изучив фреймворк, можно избежать злоупотребления им.

2017-06-28 17:38:59

• Изучая упорядоченный набор Set, столкнулся с концепцией словаря. Нужно изучить Lex.

Код и оценка не так важны, главное — архитектура

2017-06-21 18:28:38

• Стоит уделять внимание стандартам кода. Если выработать привычку следовать стандартам, проблем не будет.
• Эти платформы служат лишь ориентиром, не стоит тратить на них слишком много времени. А вот на покрытие кода тестами стоит обратить внимание.

Long и long, а также использование тестового фреймворка Jmockit

• Long — это просто класс-оболочка для long, поэтому при утверждениях будут возникать ошибки.
• То же самое относится к Float, Char, Byte и Integer — они тоже являются упакованными типами.

Проблемы с журналами

2017-06-14 23:47:26

• Напротив, введение зависимости от commons-logging решило проблему. Это стоит учесть.

Проблемы с журналом Spring

• java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
• Особое внимание следует уделить тому, что если используется другая реализация slf4j, кроме apche, то необходимо исключить зависимость.

    <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-webmvc</artifactId>
          <version>${spring.version}</version>
          <exclusions>
              <exclusion>
              <groupId>commons-logging</groupId>
              <artifactId>commons-logging</artifactId>
              </exclusion>
          </exclusions>
    </dependency>

• В Gradle исключение зависимостей всё ещё вызывает проблемы. Приходится использовать простой статический класс. Однако каждый раз при операции создаётся новый экземпляр, так что стоит рассмотреть возможность использования одноэлементного шаблона?

Ошибки кодирования и пользовательские исключения

2017-06-12 08:27:06

• Перечисления — это фиксированные неизменяемые экземпляры, которые по умолчанию наследуются от класса java.lang.enum и не могут быть явно унаследованы от другого класса.

Завершение работы над пулом соединений, следующие шаги

2017-06-11 20:14:24

• О версии Redis в управлении версиями? cluster shared (кластерный общий доступ).
• В классе много методов, и классов много, но методов мало.
• Нужно ли сначала вести журнал, поддерживает ли он отмену и повтор?

В следующих случаях следует рассмотреть использование командного режима:

1. Использование командного режима в качестве замены «CallBack» в объектно-ориентированных системах. «CallBack» означает регистрацию функции, которая затем вызывается позже.
2. Необходимо указать запрос или поставить его в очередь в разное время. У команды и первоначального отправителя запроса могут быть разные жизненные циклы. Другими словами, первоначальный отправитель запроса может уже не существовать, в то время как команда всё ещё активна. В этом случае получатель команды может находиться локально или на другом адресе в сети. После сериализации команду можно отправить на другую машину.
3. Система должна поддерживать отмену команд (undo). Команда может сохранять состояние, которое можно восстановить при необходимости отмены эффекта команды. Команда также может предоставить метод redo() для повторного выполнения команды.
4. Если система хочет обновить все данные в журнале, чтобы при сбое системы можно было восстановить данные, обновив их из журнала, можно вызвать Execute() для каждой команды, чтобы восстановить систему до состояния перед сбоем. Для каждого случая использование режима является сложной задачей для всех разработчиков. Иногда из-за предвидения будущих изменений в требованиях для обеспечения гибкости и расширяемости системы используется определённый шаблон проектирования, но эти ожидаемые изменения не происходят, вместо этого возникает множество непредвиденных требований, что приводит к тому, что используемый шаблон проектирования становится контрпродуктивным при изменении кода. Такие примеры, я уверен, знакомы каждому разработчику программного обеспечения. Поэтому, основываясь на принципах гибкой разработки, при разработке программы, если текущие требования могут быть решены без использования определённого шаблона, мы не должны его вводить. Мы можем добавить этот шаблон позже, когда он действительно понадобится. Например, рассмотрим командный режим. Во время разработки запросы и ответы очень распространены, и обычно мы инкапсулируем ответ на запрос в методе, который можно назвать командой. Но стоит ли повышать этот дизайн до уровня шаблона — вопрос отдельный. Если мы используем командный режим, нам нужно ввести роли отправителя и получателя, и первоначальная логика будет распределена между тремя классами. При проектировании необходимо учитывать стоимость такого подхода.

• Недостатком является то, что большое количество команд приведёт к большому количеству классов. На данный момент это именно та ситуация, и суть в том, чтобы сделать простые команды классами команд, а затем объединить их для достижения желаемой функциональности.
• Поэтому после рассмотрения было решено не использовать командный режим, поскольку введение ролей отправителя и получателя усложнит код.