Рефакторинги на уровне класса

17. May 2010

 

Перемещение метода и/или поля ( Move Method / Move Field ).

    Это рефакторинги, которые все ставят на свои места. Применяются для методов и полей, которые больше используются другими классами, чем классом в котором они лежат. Определить метод или поле в классе которое не должно быть в нем, очень просто, нужно посмотреть область их использования. Если публичный метод почти всегда используется в другом классе, может ему в том классе будет удобней? Или метод который принимает кучу параметров от других классов и почти не использует внутри себя поля класса в котором он живет. И еще один один из самых основных критериев, метод класса должен соответствовать назначению класса. Если класс занимает отправкой почты, то в нем не должно быть открытых методов связанных с вычислением бизнес данных. Если такие методы все же есть их лучше отправить жить в другой дом, дабы не портить абстракцию, которую представляет собой класс (Принцип единой ответственности в SOLID).

 

Выделение класса ( Extract Class ).

    С течением времени, если пренебрегать вторым принципом SOLID(Принцип открытости / закрытости) и давать волю своей лени, даже хорошо спроектированный класс обрастает методами и полями, которые выполняют не совсем функции этого класса и не соответствуют единой абстракции которую олицетворяет класс  (Принцип единой ответственности). Когда у класса появляются дополнительные возможности и обязанности или некоторые методы и поля необходимы для выполнения другой задачи. В таком случае нужно провести рефакторинг 'выделение класса' и вынести методы и поля в новые классы, который будет выполнять эти обязанности. Полученные классы так же должны соответствовать первому принципу SOLID, а не быть просто контейнером для разносортной всяких бездомных методов. 

More...

Refactoring, Architecture

Рефакторинги уровня метода

10. May 2010

 Рефакторинг - это изменение кода в лучшую сторону. Улучшения стремятся привести код в соответствие с SOLID принципами.

    По своему масштабу рефаторинги могут проводится в границах следующего масштаба:

  • Уровня метода/процедуры/функции
  • Уровня отдельно взятого класса
  • Уровня взаимодействия объектов
  • Уровня ветвления выполнения(условные выражения)
  • Уровня интерфейса классов
  • Уровня иерархии классов
    Классификация не полная, например, тут нет рефакторинга кода работающего параллельно.

Рефактори уровня метода/процедуры/функции.

 

Самый популярный рефакторинг - это Выделение метода(Extract Method).

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

    Плюсы. Имя нового метода станет отличным комментарием поясняющем, что делаю вынесенные операции. Выделенный метод можно использовать в другом месте, а не copy-past-ить код, так проще вносить изменения. Исходный большой метод стал меньше и понятней.

    Минусы.  Мы можем получить ситуацию когда в выделенный метод придется передавать тучу параметров и возвращать специально созданные для этих целей структуры данных. Этого делать нельзя!

    Метод не должен получать больше 4-5 параметров, иначе его сигнатура становится не читаемой. Так что без фанатизма, если не дается кусочек рефакторингу - то и бог с ним. Пример кода.

More...

Refactoring, Architecture ,

Раздумья над Фаулером

8. May 2010

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

Мысли по первым двум главам.


О Производительности:

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

    Почти всегда? если вы боретесь за производительность пострадает понятность кода. И наоборот.

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

 

О Проектировании:

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

More...

Refactoring, Architecture , , ,

Adapter (Wrapper). Шаблон проектирования.

27. December 2009

Гипотетический случай из жизни:
    Представьте, что вы сантехник и пришли поставить новый кран клиенту. Клиент вас встречает, чаем угощает, рассказывает "так мол и так, кран потек :-'( Надо новый ставить, стрый совсем плохой стал." Дает в руки вам смеситель, который вчера купил и провожает в ванную. Вы достаете разводной ключ и лихо откручиваете старый смеситель и уже собираетесь привернуть новый, как замечаете, что у наих трубки подвода воды разных диаметров. И тут вы могли бы сказать клиенту, что он не то купил и уйти, но чай выпит, в карманах пусто, а заработать хочется. Что делать?! Хорошо с собой есть такая классная штучка как муфта! С одной стороны она отлично наварачивается на трубки которые подводят воду, с другой замечательно вкручивается в новый смеситель, да и сама размером длинной пару сантиметров не более. Работа сделана, деньги в кармане, клиент доволен, проблема побеждена. Молодцы? А то!
 
Случай из практики разработки программ:
    А теперь вернемся обратно к программированию, а именно к шаблонам проектирования. Скажите, у вас случалась ситуация, когда несколько человек проектирую одну систему, предварительно разделив ее на компоненты, а когда настает время соединить все вместе, то оно не соединяется. Ну не стыкуется один код с другим и все! Методы делают то, что нужно, а интерфейсы разные. Количество параметров не совпадает или нельзя просто вызвать метод, нужно еще предварительно настроить объект, который содержит метод.  Проблема... :-( И что теперь делать? Деньги на разработку компонентов потрачены, менять интерфейсы стыковых классов нельзя(это, вроде как, основное ограничение), потому что они завязаны еще много где и придется перелопачиваться и там. А изменения там потребуют изменений еще где нибудь... Затратно это и рисковано!
 
    Или так. Представьте, что нашли нужную библиотеку компонентов, а интегрировать со своим кодом не можете, интерфейсы разные. Изменить интерфейсы библиотеки тоже не можете, исходников нет и вообще по лицензии запрещено, что либо менять)
Основная проблема в том, что нужно использовать компоненты интерфейс которых не совпадает с интерфейсом, которого вы ожидаете в использовании.
 
    Ситуация напоминает ситуацию со смесителем, да? Тут решение такое же, нам нужен специальный переходник - Адаптер. Этот Адаптер приведет интерфейс используемого класса к интерфейсу, который ожидает класс использующий его(клиент). Проблема будет решена, интеграция компонентов пройдет успешно и довольные разработчики наконец пойдут отмечать успех!
 More...

Architecture, Design Patterns , ,

Decorator. Шаблон проектирования

26. December 2009

    Это структурный шаблон проектирования, который применяется когда нужно добавить определенную функционально отдельному объекту, а не целому классу.

    Допустим у нас есть Объект который что-то делает с другим объектом. Например, сохраняет какой либо файл на диск, сериализует в xml и сохраняет.

    Проходит время, этот класс уже используем в 1000 мест в проекте.

    И тут понимаем, что нельзя хранить наши объекты просто сериазиованными, их могут открыть простым текстовым редактором и прочесть важную информацию! Не безопасно!Нам нужно добавить к классу Writer новую функциональность шифрования.

    Описание проблемы:
    Нужно изменить поведение объекта только в нескольких местах. В зависимости от ситуации может потребоваться несколько вариантов расширения поведения(возможны комбинации добавляемых  функций: шифрование и сжатие, шифрование и подпись ключом)

    Как это сделать? Менять сам класс, нельзя, т.к. мы хотим использовать так же и сохранение данные без шифрования. Можем сделать наследника от Writer и переопределить метод Write, чтоб тот предварительно все шифровал. Наследование, вроде подходит.. А представим, что нам нужно применять шифрование опционально, в зависимости от выбора пользователя добавлять шифрование, сжатие, подписывание ключом. Мы будем создавать наследников для всех этих случаев? И для их комбинаций тоже? Не очень красивое решение. В такой ситуации хорошо подходит использовать шаблон Декоратор.

More...

Architecture, Design Patterns ,

Технология ClickOnce

22. July 2009

 Речь идет о технологии развертывания .NET приложений.

Приложения ClickOnce  - это приложения .NET(Console, WinForms, WPF) и С++, которые были опубликованы с помощью технологии развертывания ClickOnce. Теоретически при помощи утилит Mage и MageUI можно развернуть любое исполняемое Windows приложение.

Приемущества по сравнению с другими способами развертывания(xcopy, WindowsInstaller).

ClickOnce приложения может попасть в руки пользователю из разных источников: 

  1. C Web-Страницы или сетевого каталога. 
  2. С компакт диска или любого другого сьемного носителя. При публикования дистрибутива autorun генерируется автоматически.
  3. Пользователь может сразу запускать приложения, без его установки на свой ПК. Фактически, приложение копируется в Кэш ClickOnce. Кстати, его размер по умолчанию 250 мб, находится кеш в пользовательском каталоге, а значит не доступен другим пользователям. Чтоб изменить его размер нужно изменить один ключь в реестре. Подробней в msdn.
ClickOnce предоставляет гибкие средства для обновления приложений пользователя. Теперь не нужно рассылать письма "Вышла новая версия, скачайтее ее тут". Приложения теперь обновляются автоматически. Обновляться будут только те файлы которые изменились(изменения определяются по хешам файлов).
Проверка наличия обновления может быть:
  1. До запуска приложения. Если есть новая версия, пользователь будет работать с ней, иначе со старой.
  2. После запуска. Пока пользователь работает с вашей программой, .NET, с определенной периодичностью, в фоне, будет проверять наличие новой версии. При следующем запуске будет предложено обновить версию.
  3. Разработчик может реализовать свой вариант обновления, для этого предоставляется специальный API.
В дополнение, можно установить минимальную версию приложения для запуска. Если установить последную версию как минимальную, пользователь не сможет работать с приложением не обновив его.
По умолчанию ClickOnce приложения выполняются в контексте безопасности Internet. Приложению предоставляется минимум ресурсов.

  Процесс создания дистрибутива, называется опубликование(publish). Во время этого процесса в целевой директории на диске или в сети / ftp ресурсе /IIS приложении создается иерархия каталогов с необходимыми файлами. В отличии от WindowsInstaller, в  ClickOnce монолитного дистрибутива нет. Как раз это и позволяет производить обновление только изменившихся файлов.


 

Основные составляющие ClickOnce приложения: 

  1. Манифест приложения.
  2. Манифест развертывания.
  3. Развертываемое приложение и все его компоненты. 

Пример каталога полученного в результате публикации приложения с названием "<AppName>". 

  • PublishDir
    • <AppName>.application [Основной манифест развертывания, как раз его и должный запрашивать пользователи.]
    • Publish.htm   [html файл, генерируется автоматически. Основная задача указать ссылку на скачивание файла манифеста развертывания <AppName>.application
    • <AppName>_1_0_0_1.application [маниест развертывания соответствующий версии, создается для каждой новой версии]
    • <AppName>_1_0_0_1 [папка в которой содержатся все файлы приложения данной версии, а так же манифест приложения, создается для каждой новой версии] 
      • <AppName>.exe.deploy [расширение ".deploy" добавляется ко всем файлам приложения, по умолчанию. Это упрощает процесс настройки прав доступа к файлам на вебсервере. Нужно разрешить вебсевиру отдавать пользователю только файлы с расширением ".deploy", ".manifest", ".application".]
      • <AppName>.exe.manifest [манифест приложения.]

  


 Создать ClickOnce приложение можно несколькими способами: 

  1. Через Visual Studio - самый простой, но с ограничениями.
  2. При помощи MSBuild из консоли. 
  3. При помощи консольной утилиты Mage.exe из .NET SDK или ее более дружелюбного варианта под названием MageUI.exe.
Используя MSBuild или mage.exe можно добится полностью автоматизированного опубликования приложения. Например, публиковать новую версию при каждом удачном TeamBuild в Team Foundation Server или по расписанию.
Самое большое ограничение при создании  ClickOnce через MSBuild или VisualStudio в том, что конечный список файлов состоит только из исполняемых модулей проекта и проктов связанных с ним ссылкой(References). Если мы хотим добавить какой-либо Help или Config файл который не включен в публекуемый проект, стоит использовать утилиты mage или MageUI (лежат они в .NET SDK). 

Обзор практической части развертывания порекомендую смотреть доклад на TechDays.ru (http://www.techdays.ru/videos/1274.html


 

Всякие мелочи.

 

  1. Есть возможность. Задать URL службы тех поддержки для вашего приложения.
  2. Вы можете подписать свое ClickOnce приложение сертификатом выданным центром сертификации. Тем самым вы подтвердите, что разработчик этого приложения именно вы, а не какой-нибудь хитрый трояно писатель.
  3. Если вашему приложению требуются какие либо особенные компоненты, например, .NET 3.5 и не сотой ниже. В случае отсутствия требуемого компонента, пользователю будет предложено скачать недостоющую часть(источник можно задать произвольный).

 


Плохая новость.

Работает ClickOnce это только в IE. Для Firefor и Opera необходимо поставить соответствующий плагин или конфигурировать браузер.

Плагин для FireFox.

Настройки для Opera:

Идем в Tools->Preferences->Advanced->Downloads ->Add..

Устанавливаем параметры:  

MimeType: application/x-ms-application 
Extension: application
Select Open With Other Application:  explorer.exe ( он обычно в папке Windows лежит)
Ставим галку напротив "Pass Web Address Directly To The Application ".

Попробовать поставить приложение ClickOnce можно тут. RiotClipboard.

ClickOnce в интернетах:

http://wiki.dodex.org/?p=447 

http://www.c-gator.ru/articles/deploying/

http://www.techdays.ru/videos/1274.html 

http://msdn.microsoft.com/ru-ru/library/142dbbz4.aspx 

.NET, Visual Studio , ,

Сертификация Microsoft

1. January 2009

Что это такое и зачем это нужно?

Ответы на эти вопросы можете прочесть здесь - Обзор программ сертификации Microsoft.

Экзамен проводится в виде тестирования, в среднем 40-60 вопросов, на каждый из которых представлено несколько ответов. Нужно выбрать один или несколько. 

В основном, наличие в активе сданных экзаменов и сертификатов дает:

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

Какой экзамен выбрать можно найти на сайте Microsoft, начиная со ссылки выше.

Ок,экзамен выбран! теперь вопрос...

Как готовиться к экзамену?

  1. Перво-наперво прочитать preparation guide (найти его можно тут, ищем по коду экзамена и словам preparation guide )
  1. Второй шаг, выбираем источник знаний. Если вы последние 5-ть лет создавали сайты на asp.net и в тонкостях знаете возможности фреймворка, то можете пропустит этот шаг, в противном случае стоит выбрать источник знаний, так называемый Traning kit.
  • Можно воспользоваться авторизованными курсами Microsoft. Для одного экзамена требуется прослушать 2-3 курса и позаниматься самостоятельно( на курсах дают не все). Вариант дорогой. Один день стоит в среднем 4-5 тысяч рублей, в курс, обычно, входят 3-4 дня. 
  • Можно заказать электронную обучающую версию. Вряд ли есть локализованные версии на русском языке.
  • Можно купить книжку и готовится по ней. Это мой вариант. Мелкомягкие выпустили несколько книг от "Microsoft press" для подготовки к своим экзаменам. Книжки не подробные и не исчерпывающие, доверяться информации, подчерпнутой только из них, нельзя. Многие переведены на русский и выпущены издательством "Питер". Перевод плох (будто электронный переводчик поработал), большое количество опечаток, слов, набраных не в той раскладке, местами copy-paste. Но там освещены именно те области, которые будут спрашивать в экзаменационном тесте. Рекомендую обзавестись одной книжкой по экзамену и одной или несколькими от других издательств по тематике экзамена. Когда готовился к экзамену 70-528  - очень понравилась книга от Apress про ASP.NET 2.0. 

Итак, вы готовы к экзамену. Из preparation guide, узнали какие знания потребуются во время тестирования. Сходили на курсы/послушали интернет лекцию/прочли одну или несколько книжек и полистали msdn.

Пришло время найти место, где можно сдать экзамен.

Где искать?

Сертификацией по микрософтовским экзаменам занимается только одна фирма - Prometric (www.prometric.com) На сайте Прометрика располагается мастер для поиска центра тестирования. Указываем страну, чей экзамен будем сдавать и программу сертификации( Microsoft ), читаем условия сдачи, выбираем экзамен, язык, валюту в которой хотите расчитаться и видим адреса центров тестирования. Свой город придется искать глазами. Дальше пишем или звоним туда и договариваемся о дате и времени сдачи.

Если вы завалили экзамен - не отчаивайтесь! Его можно пересдать! Первый раз заявку на пересдачу можно отправить спустя 24 часа(если данные о провале экзамена еще не дошли до Prometric'а, вы будете считаться еще сдающим этот экзамен и вам не дадут его зарегистрировать повторно).  Если вы завалили тест больше одного раза, то придется ждать 14ть дней до подачи заявки на пересдачу.

Экзамен завершен, и у вас на руках лист с результатами экзамена (Test Score). Для того, чтобы информация о успешной сдачи экзамена дошла до Microsoft'а и вам открыли доступ к секретным разделам сайта нужно подождать сутки. Или связаться с Микросовтовской службой поддержки и выслать им сканы вашего Test Score. Вы получите письмо с дальнейшими инструкциями по регистрации.

Вот и все, ребятки;) 

Если есть какие вопросы или дополнения пишите в комментарии или по почте.

 

Exam ,

Итог 2008 года

25. December 2008

Я наконец стал сертифицированным специалистом в области применения .NET технологий.

 

      

 Для получения таких логотипчиков(и не только) в  требовалось сдать пять экзаменов:

70-536 (является необходимым для получения любого MCTS для 2.0)

70-526(вместе с 70-536 дает MCTS Win Application)

70-528(вместе с 70-536 дает MCTS Web Application)

70-529(вместе с 70-536 дает MCTS Distributed Application)

и как шаг от набора MCTS к MCPD - 70-549(Design and Development Enterprise Application)


В планах на следующий год познать SQL и сертифицироваться по нему.

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

 

Exam , , ,

Ключ на старт!

15. December 2008


Нашел свободный движек для блога на ASP.NET (BlogEngine.NET). Второй день ставлю=) Из любопытства на хостинге заказал iis7 вместо шестого, вот теперь преодалеваю глюки с конфигурацие модулей и хендлеров. Впереди много интересного проверка настроек, написание или конфигурирование провадеров для работы с БД, нормальная локализация(варианты перевода "чуть тут,чуть там" не круто^^), ту же хендлеры(пора искать бук по IIS 7) ну и другие доработки и доделки.

Осваиваюсь в общем)

 

ps: только я тыкнул "Сохранить запись", как увидел эксепшен 404 =) Урл не зареврайтился из за отсутствующих модулей)

,