Метка «pattern»

MVVM Framework для Windows Phone своими руками. Часть 1 Разработка приложений для платформ WPF, Silverlight, Windows Store и Windows Phone, почти всегда подразумевает использование паттерна MVVM. Это закономерно, так как базовой философией этих платформ, является разделение представления (так же я буду использовать термин интерфейс пользователя) и остальной логики программы. Этот подход позволяет получить следующие преимущества:

  1. Разделение пользовательского интерфейса и логики представления: что позволяет дизайнерам работать над пользовательским интерфейсом, а программистам над бизнес логикой приложения используя для взаимодействия абстрактный интерфейс модели представления
  2. Расширенные возможности автоматизированного тестирования: отделение пользовательского интерфейса от остальной логики, позволяет полностью протестировать логику представления без ограничений накладываемых автоматизацией тестирования через пользовательский интерфейс
  3. Множественные представления для одной модели представления: одна модель представления может использоваться многими реализациями интерфейса пользователя. Например, сокращенный и полный вариант представления данных, интерфейс зависящий от прав пользователя. Возможность использовать одну реализацию модели представления на различных платформах
  4. Расширенные возможности повторного использования компонентов: так как модели представления отделены от реализации представления, возможны любые варианты их использования, наследование от базовых моделей, композиция нескольких моделей и т.п.

Разрабатывая приложения под платформу Windows Phone, я столкнулся с тем, большинство статей описывают базовую реализацию паттерна MWWM, которая обычно сводится к реализации в классе модели представления интерфейса INotifyPropertyChanged, создания простой реализации ICommand и простые сценарии связывания этих данных с представлением. К сожалению, остаются за рамками обсуждения такие важные вопросы как, реализация обобщенных классов с удобным интерфейсом, синхронизация потоков при асинхронном исполнении, навигация на уровне модели представления и многие другие.

Читать полностью »

Работа с Корутинами в Unity
Корутины (Coroutines, сопрограммы) в Unity — простой и удобный способ запускать функции, которые должны работать параллельно в течение некоторого времени. В работе с корутинами ничего принципиально сложного нет и интернет полон статей с поверхностным описанием их работы. Тем не менее, мне так и не удалось найти ни одной статьи, где описывалась бы возможность запуска группы корутинов с продолжением работы после их завершения.
Хочу предложить вам небольшой паттерн, реализующий такую возможность, а также подбор информации о корутинах.

Читать полностью »

Доброго времени суток!
Model-View-Presenter — довольно известный шаблон проектирования. С первого взгляда все выглядит просто: есть Модель (Model), которая содержит всю бизнес-логику экрана; Вид/Представление (View), который знает, как отобразить те или иные данные; Представитель (Presenter), который является связующий звеном — реагирует на действия пользователя во View, изменяя Model, и наоборот.
Сложность начинается, когда количество форм в проекте становится более одной.
В данной статье рассматривается:
— немножко теории;
— общие проблемы реализации MVP (а именно Passive View) под Windows Forms;
— особенности реализации переходов между формами и передача параметров, модальные окна;
— использование IoC-контейнера и шаблона Dependency Injection — DI (а именно Сonstructor Injection);
— некоторые особенности тестирования MVP приложения (с использованием NUnit и NSubstitute);
— все это будет происходить на примере мини-проекта и постарается быть наглядным.
В статье затрагивается:
— применение шаблона Адаптер (Adapter);
— простенькая реализация шаблона Контроллер приложения (Application Controller).
Для кого эта статья?
Главным образом для начинающих разработчиков на Windows Forms, которые слышали, но не пробовали, или пробовали, но не получилось. Хотя уверен, что некоторые приемы применимы и для WPF, и даже для веб-разработки.
Читать полностью »

По долгу службы мне периодически приходится пользоваться профайлером, так как требования к производительности серверов задокументированы и не могут опускаться ниже определенного уровня. Помимо некоторых очевидных архитектурных изменений и решений частенько находятся повторяющиеся места от модуля к модулю, от одного проекта к другому, которые создают дополнительную нагрузку на виртуальную машину, которыми и хочу поделится.
Так уж случилось, что на глаза чаще всего попадался код работы с Date потому с него и начнем:

Date

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

    public boolean isValid(Date start, Date end) {
        Date now = new Date();
        return start.before(now) && end.after(now); 
    }

Казалось бы — вполне очевидное и правильное решение. В принципе, да, за исключением двух моментов:

  • Использовать Date сегодня в java — уже, пожалуй, моветон, учитывая тот факт, что почти все методы в нем уже Deprecated.
  • Нету смысла создавать новый объект даты, если вполне можно обойтись примитивом long:

    public boolean isValid(Date start, Date end) {
        long now = System.currentTimeMillis();
        return start.getTime() < now && now < end.getTIme(); 
    }
SimpleDateFormat

Очень часто в веб проектах возникает задача перевести строку в дату или наоборот дату в строку. Задача довольно типичная и чаще всего выглядит так:

    return new SimpleDateFormat("EEE, d MMM yyyy HH:mm:ss Z").parse(dateString);

Это правильное и быстрое решение, но если серверу приходится парсить строку на каждый пользовательский реквест в каждом из сотен потоков — это может ощутимо бить по производительности сервера в виду довольно тяжеловесного конструктора SimpleDateFormat, да и помимо самого форматера создается множество других объектов в том числе и не легкий Calendar (размер которого > 400 байт).

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

Вторая мысль — использовать синхронизацию. Но это таки довольно сомнительная вещь. В случае большой конкуренции между потоками, мы можем не просто не улучшить производительность но и ухудшить.

Но решения есть и их как минимум 2:

  • Старый, добрый ThreadLocal — cоздаем SimpleDateFormat для каждого потока 1 раз и переиспользуем для каждого последующего запроса. Данный подход поможет ускорить парсинг даты в 2-4 раза за счет избежания создания объектов SimpleDateFormat на каждый запрос.
  • Joda и ее потокобезопасный аналог SimpleDateFormat — DateTimeFormat. Хоть йода в целом и медленнее дефолтного Java Date API в парсинге дат они идут наравне. Несколько тестов можно глянуть тут.

Читать полностью »

Паттерны JavaScript модулей в Impress для node.js и браузеровУ меня сложилось впечатление, что в обществе все же есть предубеждение против использования глобальных переменных в служебных целях. В связи с этим, хочу дать некоторые разъяснения с примерами, которые снимут всякие сомнения и будут полезны всем, кто жаждет модульности и гибкости в JavaScript разработке. Я не могу проследить источники всех идей, приведенных ниже, но я не претендую на их авторство, а лишь на творческое обобщение. Так же я отказываюсь от претензий на один универсальных паттерн определения модйлей для всех случаев жизни, надеюсь, всем ясно, что такого не может быть никогда. Все это существенно отличается от подходов RequireJS, CommonJS и того, как модули оформляются в node.js через module.exports, однако, каждый из этих паттернов имеет свое место, если подходить к задаче без фанатизма и предубеждений.
Читать полностью »

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

Ситуации взаимной блокировки

В Википедии дается следующее определение взаимной блокировки: «Взаимная блокировка (англ. deadlock) — ситуация в многозадачной среде или СУБД, при которой несколько процессов находятся в состоянии бесконечного ожидания ресурсов, занятых самими этими процессами».

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

Классический пример взаимной блокировки: первый поток (A) захватывает мьютекс M1 и следом мьютекс M2. Второй поток (B) захватывает мьютекс M2, а уже после этого – мьютекс M1. Взаимная блокировка этих двух потоков может произойти следующим образом: поток A захватывает M1, поток B захватывает M2, после этого оба потока «обречены»: ни поток A не может захватить M2, ни поток B не может захватить M1; попытки захвата мьютексов заблокируют оба потока.

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

Данная ситуация очень распространена в сложных многопоточных системах. Как правило, мьютексы-участники расположены далеко друг от друга (в различных компонентах системы), и выявить участников взаимной блокировки оказывается достаточно сложно.
Читать полностью »

Шаблон программирования «Текучий интерфейс» в PHP. Свежий взгляд
При разработке программного обеспечения одной из важных составляющих является высокая читабельность исходного кода программы. Существуют специальные методики и рекомендации, которые позволяют добиться улучшения читабельности исходного кода. Одной из методик улучшения читабельности исходного кода является применение «текучих интерфейсов» (англ. Fluent Interface). О нем мы и поговорим в данной статье.
Читать полностью »

Содержание

I. Описание проблемы
II. Обзор существующих решений
III. Вариант решения без применения аспектов.
IV. Решение на AspectJ
V. Динамические аспекты
VI. Послесловие.
VII. Ссылки и литература
Читать полностью »

Здравствуй,!

В этой коротенькой статье хочу поделиться полезной фичей от Photoshop.
Да простят меня гуру дизайна, если это покажется очевидным.
Все же, думаю, для начинающих и «среднячков», коим я и являюсь, полезность покажется весьма пригодной.

Функция Crop в фотошоп особо ничем не отличалась. Но в CS6 решили добавить Perspective Crop.

Случайность

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

image

На первый взгляд ничего особенного, картинка как картинка.
Но при ближайшем рассмотрении виден недостаток фотографии — легкая перспектива.

Читать полностью »