Dmitrii Volyx

В файле какого-нибудь изображения хранится очень много всякой полезной информации, например: дата съемки, размеры, всякие уровни компресии, марка и модель фотоаппарата и т д … Хотелось бы как-то получить ее в java Все это в java можно вытащить с помощью удобной библиотеки metadata-extractor. Она умеет понимать следущие форматы: Exif IPTC XMP JFIF / JFXX ICC Profiles Photoshop fields PNG properties BMP properties GIF properties Например вот Exif А вот краткий пример на groovy, который позволяет получить достаточно много информации ...

Белая береза Под моим окном Принакрылась снегом, Точно серебром. На пушистых ветках Снежною каймой Распустились кисти Белой бахромой. И стоит береза В сонной тишине, И горят снежинки В золотом огне. А заря, лениво Обходя кругом, Обсыпает ветки Новым серебром. ‹1913›

Cтруктура, известная у программистов как дерево, используется довольно часто. Соответственно, так же часто возникает проблема отладки кода, который работает с этой структурой. Очень удобно иметь под рукой удобный метод “toString()”, который нарисует это дерево, например в консоли в графическом виде. Печатает дерево в консоли, с помощью System.out public void print(TreeNode root) { print(root, "", true); } private void print(TreeNode root, String prefix, boolean isTail) { System.out.println(prefix + (isTail ? "└── " : "├── ") + root.toString()); List<TreeNode> children = Collections.list(root.children()); for (int i = 0; i < children.size() - 1; i++) { print(children.get(i), prefix + (isTail ? " " : "│ "), false); } if (children.size() > 0) { print(children.get(children.size() - 1), prefix + (isTail ? " " : "│ "), true); } } Вывод: ...

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

Простой кейс: у вас лежит где-то папка с фотографиями, которые используются в блоге и жестко “закодированны”, но размер их очень большой. Загрузка страницы занимает около МИНУТЫ! Итак, ваша задача изменить параметры каждой фотки, не меняя названия и к тому же сохранить исходные фотографии. Можно конечно надолго зависнуть в интернете и потратить время на изучение и опробование разных готовых бесплатных программ, или можно быстро на коленке написать свое решение например на groovy! ...

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

Добавить новое поведение в существующий метод легко, но часто это бывает не совсем верным решением. Когда изначально создается какой-то метод, то он обычно делает строго одно действие. Любое добавление нового кода выглядит немного подозрительно. Скорее всего, вы добавляете новый код, потому что хотите, чтобы он выполнялся в одно время с уже существующим кодом. Раньше, такой способ называли “временным связыванием”, код становится довольно некрасивым, если делать это слишком часто. Если группировать процедуры вместе только потому что они должны выполняться в одно и тоже время, то связь между ними весьма слаба. Позже может выясниться, что один метод не используется без другого, и с этой точки зрения они должны логически быть одним методом. Но не торопитесь склеивать их в один метод, потому что вернуть назад может быть нелегко. ...

Ветвление методом это хорошо, но в некоторых ситуациях, например с кучей зависимоcтей, этот подход проигрывает другой технике. Рассмотрим ситуацию, когда вы должны внести изменения в класс, но нет никакой возможности создать зависимые объекты для тестирования. Получается, что не возможно вставить ответвляющийся метод и покрыть его тестами. Возможно, ваш класс просто зависит от тяжелых в создании объектов или имеет какие-то скрытые зависимости. Чтобы избавится от них, вам нужно сделать глубокий рефакторинг и отделить их, для того чтобы протестировать.

Такая ситуация наверняка была с каждым. Представьте к вам подходит ваш начальник и говорит: - Клиенты требуют от нас новую фичу - сможем мы сегодня ее добавить? Обычно все что вы можете пролепетать в ответ это:- Я не знаю… смотря куда …. смотря что … И тут вы задумываетесь… Ну, допустим, мы сможем ее быстро добавить. А как мыпротестируем, что ничего не сломали? А в слух говорите, что-то типа:- А как срочно она нужна?Вы понимаете , что нужно будет сделать это изменение в 10 местах и это займет 5 часов, но в конечном итоге мы никак не сможем удостовериться, что код работает правильно и что на других концах приложения ничего не отвалилось!

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