LINUX.ORG.RU

Проектирование настольных приложений.

 , ,


1

4

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

Многие начинают разработку с «открыл дизайнер форм, кинул кнопку, кликнул на ней - начал писать код который загружает дынные» - этот подход многие заучили как единственно верный еще в с таких платформ как 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 и специфичные для различных компонентов (в т.ч. графических, что на мой взгляд не является хорошим примером).

взято из моего жж (тамже некоторые иллюстрации)

Deleted

Последнее исправление: Deleted (всего исправлений: 2)

Ну ты бы хотя бы с большой буквы писал абзацы-то. И отформатировал. Невозможно же читать.

Zhbert ★★★★★
()

Это для поисковых ботов?

Debasher ★★★★★
()
Ответ на: комментарий от Zhbert

ну кое чего поправил, но тут особо не отформатируешь

Deleted
()
Ответ на: комментарий от Zhbert

то title ль картинк были ('images_0На рисунке' от ctrl+c из блога) в хистори можешь глянуть, а первый да, это я тут уже написал

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от koteika

когда впервые лучше начать с текстового редактора - затем добавить что-то (напр. поиск) и попробовать написать ко всему юнит тесты. Еще лучше сначала юнит тесты, а потом прикручивать это к «кнопочкам» - так более менее появится ощущение как это все должно выглядеть.

заодно почитать азы «Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес Приемы объектно-ориентированного проектирования. Паттерны проектирования» - только не все что там написано, а те главы где рассказывается как они проектировали текстовый редактор.

Deleted
()
Ответ на: комментарий от Deleted

Я просто ни когда не задумывался об этом... Програмлю давно, но только для мк, то есть прог для компов не писал... Вот на днях открыл для себя Vim.. И сразу отпало желание пользоваться какими либо иде..

Ну и начал изучать си под пингвина.. Пока что успехи)

koteika
()

Прочитал первые 2 строки, там дальше про MVC? Мне страшно, когда людей, не знающих даже таких простейших паттернов допускают до компьютеров.

unt1tled ★★★★
()
Ответ на: комментарий от koteika

а ну тогда это вообще другой мир, для мк никогда не писал (хотя даже книжку купил) а по работе во всякий интерпрайз где команды и тонны странного кода который надо както организовывать чтобы все потом не погрязли в сем

Deleted
()
Ответ на: комментарий от unt1tled

, там дальше про MVC

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

Deleted
()
Ответ на: комментарий от Deleted

это нормально, когда статья начинается так

превратить лор в хабр зафлудив его унылыми статьями собственного производства

unt1tled ★★★★
()
Ответ на: комментарий от unt1tled

это нормально, когда статья начинается так

ну этож лор, тем более что тут можно найти и mvc и трехзвенку увидеть но без базы и черта в ступе, потому что основные идеи в двух подзаголовках - а дальше разжевывание.

очевидно что если кто-то собаку съел на проектировании то ему это будет общеизвестно и крайне уныло

Deleted
()
Ответ на: комментарий от Deleted

очевидно что если кто-то собаку съел на проектировании то ему это будет общеизвестно и крайне уныло

так-то оно так, но тут материал первого курса по UI и не уныло будет только школоте

unt1tled ★★★★
()
Ответ на: комментарий от Deleted

для нешколоты первая строка

вот именно, меньше кормите необразованных иллюзиями о том, что они могут чему-то научиться из статьи на хабре, ато они ведь потом чьими-то сотрудниками становятся

ты не с другого ли глобуса?

нет, просто меня так учили

unt1tled ★★★★
()
Последнее исправление: unt1tled (всего исправлений: 1)
Ответ на: комментарий от unt1tled

они ведь потом чьими-то сотрудниками становятся

те что мне попадались требовали вообще обучения с нуля (за некоторым исключением)

нет, просто меня так учили

точно, и шо это за вуз MIT?

Deleted
()
Ответ на: комментарий от Deleted

хаха, нет, не MIT, просто не в россии

upd: кстати, сейчас вспомнил, таки да, обучение на многих курсах было построено по тому же материалу, что и в MIT :)

unt1tled ★★★★
()
Последнее исправление: unt1tled (всего исправлений: 1)
Ответ на: комментарий от unt1tled

это многое объясняет, у нас лучший вуз в краснодаре и там борланд си буилдер (и дельфи на других какультетах) щас вроде все просто сменилось на BDS

и учили обходить графы, сортировать и прочие незаменимые™ на практике вещи (не ко что понадобилось при runtime анализе движения транспорта - много разрабов с этим сталкиваются?), а проектированию вообще никак не учили.

Deleted
()
Ответ на: комментарий от Deleted

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

loz ★★★★★
()
Ответ на: комментарий от loz

гораздо полезнее имхо чтобы это все работало через сеть

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

а сабж - это IDE, в частности графические редакторы для бизнес процессов, графические реакторы диаграмм вроде visio (одну из таких я и писал, крайне жалко closed source) и т.п.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

не, сеть это для веба

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

loz ★★★★★
()
Ответ на: комментарий от loz

тормозить будет

вобще работать полностью в том окружении

это называется не работать а симулировать

для создания окружения из офиса мне достаточно ssh (можно vpn) - ide запущена на моем компе всякие ci, репозитории и бд - там. Кто не осиливает для них есть vnс и rdesktop.

Deleted
()

и последующих приемников

и передатчиков

Harald ★★★★★
()

для годных подходов достаточно нескольких концептуальных принципов, как то:

SOLID, в частности зависимости от абстракций - достаточно сильная вещь. Особенно, если принять, что абстракция есть по сути дела модель, а реализация есть частный случай абстракции.

Второй, не менее важный момент - не делать ничего такого раньше чем возникнет необходимость, если она действительно возникнет к тому времени.

Третий момент: формулирование требований функцинальности подсистемы - что должен делать данный элемент.

Итоговый момент: быстрая реализация принципиальной каркас-схемы на самых ранних этапах проектирования.

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

Важны концепции, а уж как это реализовать...

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.