[Посмотреть демку] (http://pecheny.github.io/GraphDragger/GraphDragger.swf)
Приложение построено по достаточно классической схеме MVC. В качестве контроллера выступает простенький конечный автомат, содержащий три режима работы приложения: обычное, перетаскивание прямоугольника, добавление связи.
Вообще, тестовые задания обычно даются мне сложнее, чем практические в силу своей абстрактности. Принимая то или иное алгоритмическое или архитектурное решение, я обычно отталкиваюсь от контекста: где и как приложение будет использоваться, планируется ли сопровождение/развитие и чьими силами и т.п. Таким образом, хотелось бы пояснить, из каких предпосылок я исходил, выбирая особенности реализации:
- Приложение самоцельно и является "вещью в себе", "наращивание" функционала не планируется, хотя и возможно, какие-то стратегии развития не принимались в учет.
- Исходя из этих же соображений я допустил некоторые упрощения: вместо типизированных ошибок выбрасывать просто строки с описание, избегать лишних проверок в модели из рассчета, что проверки выполняются снаружи, вызывать методы напрямую, вместо рассылки типизированных событий и.т.д.
- Поскольку задание должно демонстрировать навыки программирования, я принял решение не использовать сторонних библиотек, а все вещи, поддающиеся обобщению, решать на месте в максимально адаптированном под конкретное решение виде. В других условиях решая похожую задачу, я бы вероятно подумал об использовании стороннего инжектора, решения для конечных автоматов или MVC-фреймворка. Где-то это могло бы сэкономить каплю времени, где-то сделать решение более расширяемым.
- Относительно оптимизации я исходил из следующих соображений: нужно писать максимально аккуратно,
но экономить на лишней итерации обхода списка или вызова метода смысла нет, так как на текущих объемах данных (ограниченных по крайней мере размером экрана) такие оптимизации повлияют на производительность кода чуть более, чем никак; а код при этом может стать менее читаемым и дольше описываемым. - С точки зрения UX, да, я знаю о том, что перетаскивая прямоугольник, его можну утащить за пределы экрана, достать откуда его будет практически невозможно. Эта возможность оставлена сознательно: тк такое решение более четко соответствует описанному тз; в теории, приложение допускает расширение, в котором канвас может масштабироваться и двигаться.