Меня давно посещало желание превратить лор в хабр зафлудив его унылыми статьями собственного производства, представляю вашему вниманию первую ласточку
Многие начинают разработку с «открыл дизайнер форм, кинул кнопку, кликнул на ней - начал писать код который загружает дынные» - этот подход многие заучили как единственно верный еще в с таких платформ как Borland Delphi (C++ Builder) и последующих приемников на C# и Java.
После чтения всяческих умных статей про паттерны и необходимость тестирования новички открывают свой код и думают: это все хорошо, а как это применить к нашим кнопочкам?
Один подход к организации внутренней архитектуры который решит эту задачу я сейчас и поведаю в данной статье.
На рисунке - внтурнення архитектура приложения «проектируемого» в дизайнере форм, вся логика прячется в обработчиках событий контролов, тестировать это можно только вручную, повторное использование кода если и есть то в виде выделения общего кода в утилитные классы и тп. Со временем приложение будет обильно насыщаться синглтонами.
Отделение логики от представления.
Первое с чем разработчик сталкивается при вышеупомянутом подходе: чтобы протестировать код надо создать графический компонент, хуже того, нужен робот который будет «имитировать» пользователя нажимающего кнопки, осознав грандиозность сей задачи - либо отказываются от автоматического тестирования, либо внедряют таки сего робота. Оба варианта не правильны.
Да, тестировать UI нужно, но в первую очередь надо тестировать логику... и тут к некоторым приходит осознание того что... может логику стоит отделить?
Появляется сервисный слой (и наше настольное ПО приобретает некоторую схожесть с паттернами из мира entrprise приложений), отделенный от UI. Как правило возникает проблема, что оставить на стороне UI, а что в сервисном слое. Вот некоторые критерии:
- код выполняющий IO операции (в т.ч. чтение из файла) - такие операции могут блокировать поток выполнения
- код не оперирующий графическими компонентами - например если у вас есть компонент текстового редактора и вы решили организовать в нем поиск, то собственно «процедура» поиска текста и должна быть «сервисом» полностью изолированным от UI (кроме банальной возможности протестировать, это даст возможность не только протестировать сам алгоритм но и реализовать поиск по множеству файлов).
Примеры задач которые должны быть вынесены в сервисы: доступ к буферу обмена, поиск, кеширование, настройки программы.
Помимо «логической» изоляции сервисного кода, также стоит выполнять его в отдельном от графического потоке (решение стоит принимать на этапе проектирования, так как для этого потребуется асинхронное API либо на базе callback, либо с listenable future). Для правильно спроектированных сервисов которые не обращаются к графическим компонентам это не составит проблемы, зато у пользователя не будет возникать «подтормаживаний» ПО.
Реестр сервисов и контексты.
Появление множества сервисов подсказывает следующий шаг - внедрение DI фреймворка, сие решение весьма спорно, но в любом случе будет нужен некий service registry, роль которого может выполнять как DI фреймворк так и любая реализация Service Locator паттерна.
Если приложение может оперировать несколькими рабочими областями (например текстовый редактор - может открывать одновременно несколько файлов, или браузер несколько вкладок) то для некоторых сервисов (например кеша и настроек) возникает необходимость иметь экзепляр сервиса привязанный к некоторому контексту - текущему файлу, проекту и т.п. В подобных случаях реестр сервисов приобретает иерархическую структуру из нескольких уровней. Так что когда перед вами встанет задача выбора библиотеки отвечающей за функции реестра сервисов то обратите внимание на возможность наследования реестров.
Пример: IDE в которой можно открыть ресурс, при этом разработчик должен увидеть ресурсы проекта, родительских проектов и общие ресурсы (например поставляемые с rintime) - да в этом случае можно просто доработать сервис ресурсов, но затем придется доработать еще сервис настроек, кеширования и все остальные - и все их придется снабдить одинаковыми функциями по определению текущего проекта и «раскрутке иерархии», еще не возникло сомнений? В тоже время с предлагаемым подходом в сервисах достаточно указать необязательную заивисимость «родительский сервис» и при необходимости обращаться к нему, какой экземпляр сервиса использовать - задача реестра.
Полезно взглянуть на имеющиеся решения данного вопроса, например в Netbeans используется универсальный механизм Lookup ( http://wiki.netbeans.org/DevFaqLookup ) который представляет собой реализацию паттерна Service Locator, при этом наличествует глобальный экземпляр Lookup и специфичные для различных компонентов (в т.ч. графических, что на мой взгляд не является хорошим примером).
взято из моего жж (тамже некоторые иллюстрации)