upd: Изменил диаграмму и код. Расширил пример и описание.

Почитать описание других паттернов.

Предыстория

Вернувшись домой, после непродолжительных посиделок у старого друга, я обнаружил, что оставил у него свой мобильный телефон, а вместе с тем и единственный в квартире будильник. Ситуация осложнялась тем, что завтра в 8:00 надо было быть на работе. Вариант вернуться за мобильником в 11 часов вечера я даже не рассматривал. И первое, что пришло мне на ум — написать свой будильник, причем с применением паттерна «Мост», который мне и без того надо было реализовать в рамках спецкурса. Как говорится, двух зайцев… Я думаю, не стоит пояснять что лег спать я под утро, но довольный собой. А утром, ровно в 7:00 меня победоносно разбудил мой bridge-будильник, весело наигрывая мотив из TBBT.

Как я до такого докатился, читайте под хаброкатом.

Почитать описание других паттернов.

Пожалуй, начнем.
Для начала, поясню несколько организационных вопросов.

• Описание того или иного паттерна, является моей сугубо личной интерпретацией теоретического и практического материала, собранного из книг и интернет-статей;
• При построении UML-диаграмм, я буду использовать свободный редактор от компании astah, ввиду его простоты и независимости от конкретного языка или среды. При этом, диаграммы не будут отличатся изобилием картинок и цветов, но будут ясно отображать суть паттерна;
• При реализации практических примеров, язык программирования будет выбираться совершенно случайно. Однако, я буду стараться подбирать те языковые средства, на которых данный паттерн реализуется не тривиально;
• Каждый мой пост, будет содержать как минимум 5 секций — Проблема, Описание патерна, Практическая задача, Диаграмма классов и Реализация;
• Если Вы, с чем-то не согласны или у Вас есть дополнения к материалу, изложенному мной — я буду рад их почитать в комментариях. Однако, помните — я тоже изучаю паттерны вместе с Вами :)

Теоретическая составляющая.

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

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

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

У меня возник вопрос насколько все может быть плохо. Кроме того, интересно было посмотреть как влияет длина данных.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Damian Conway, co-designer of Perl 6

Хороший программный код определяется как минимум тремя признаками: однозначность, эффективность и сопровождаемость.

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

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

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

Читая Хабрахабр или просматривая чужие исходные коды, мне довольно часто приходится замечать примерно следующий кусок кода, который совершенно одинаково «звучит» на любом языке, на каком бы не был написан:

function(single_document)
{  
  if (single_document.getElementById("comments") != null)
    return;
    …
    …
    …
    …
}* This source code was highlighted with Source Code Highlighter.

Здесь приведён кусочек кода на Javascript, но то же самое можно написать на нескольких десятках других языков. Что здесь не так? Только то, что у функции (метода, свойства, процедуры) несколько точек выхода. Если вам интересно почему это плохо, прочитай то что написано под катом.

Прочел последний топик про Singleton в этой группе «Совершенный код» и вспомнилось мне недавнее сообщение в группе Google comp.lang.c++.moderated про совершенную реализацию thread safe Singleton.
Советую всем любителям C++ прочитать это сообщение и вникнуть в код в нем.

По-моему это своего рода шедевр про то, как можно стремлением к совершенству убить красоту и понятность кода и превратить его в совершенный и нечитаемый фарш.
Мое мнение, что thread safe для Singleton не нужен, т.к. проблему одновременной инициализации static переменной в Meyers Singleton можно решить более простыми способами.

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

Есть возражения или мысли на этот счет?

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

Общие сведения
Паттерн Singleton гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа.

Нашествие многоядерных процессоров и повсеместный параллелизм наступили как-то неожиданно для софтверной индустрии (компания Intel довольно резко переметнулась на многоядерные проекты в 2004 году). В результате, современные средства разработки программного обеспечения оказались совершенно не приспособлены к параллельной архитектуре ПК. А ведь практически все современные процессоры являются многоядерными, и количество этих ядер растёт у них в геометрической прогрессии: 4, 8, 16 и т.д. Если программы не научатся в самое ближайшее время эффективно использовать параллелизм, то весь технический прогресс в процессоростроении пойдёт насмарку.

Фактически, это новая чаша Грааля для компаний-разработчиков: кто первым сможет разработать компиляторы для эффективного распараллеливания программ? Здесь начинается настоящая золотая лихорадка, пишет NY Times.

Месяц назад Intel и Microsoft объявили о программе исследований в этом направлении. Они финансируют работу группы в Университете Калифорнии в Беркли. Над той же проблемой бьются исследователи из Университета Иллинойса. Сейчас стало известно, что ещё один — третий — альянс «золотоискателей» при Стенфорде (Pervasive Parallelism Lab) сформировали корпорации Sun Microsystems, AMD, Nvidia, IBM, HP и та же Intel.

Боритесь со сложностью

Как известно, мозг человека может одновременно рассматривать 7±2 элемента. Поэтому очень важно стремиться к снижению сложности ПО. Вот некоторые конкретные рекомендации:

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

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

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

Но ведь программы пишут люди, такие же, как мы с вами. Одни становятся выдающимися программистами и достигают больших успехов, другие же забрасывают профессию. Перефразируя классика, можно сказать: «покажи мне свой код, и я скажу, кто ты». Исследования показывают, что лучшие программисты создают программы в 10 раз быстрее, чем их менее квалифицированные коллеги. Время, уходящее на отладку кода, а также объем и быстродействие итоговой программы, уровень ошибок и число обнаруженных ошибок также различаются примерно в 10 раз.

В этой статье попытаемся ответить на вопрос, какими же качествами должен обладать человек для того, чтобы писать совершенный код.

«Ясно, что на некотором уровне комментарии должны быть полезны. Думать иначе означало бы полагать, что понятность программы не зависит от того, сколько информации о ней уже известно читающему программу человеку. Б. Шейл.»
Действующие лица:
ФРАСИМАХ Неопытный пурист теории, который верит всему, что читает.
КАЛЛИКЛ Закаленный в боях представитель старой школы — «настоящий»
программист.
ГЛАВКОН Молодой, самоуверенный, энергичный программист.
ИСМЕНА Опытная разработчица, уставшая от громких обещаний и просто
желающая найти несколько работающих методик.
СОКРАТ Мудрый опытный программист.

Мизансцена:
Завершение ежедневного собрания группы
— Желает ли кто-то обсудить еще что-нибудь, прежде чем мы вернемся к работе? — спрашивает Сократ.
— Я хочу предложить стандарт комментирования для наших проектов, — говорит расимах. — Некоторые наши программисты почти не комментируют свой код, а всем известно, что код без комментариев нечитаем.
— Ты, должно быть, еще менее опытен, чем я думал, — отвечает Калликл. — Комментарии — это академическая панацея, и любому, кто писал реальные программы, известно, что комментарии затрудняют чтение кода, а не облегчают. Естественный язык менее точен, чем Java или Visual Basic, и страдает от избыточности, тогда как операторы языков программирования лаконичны и попадают в самое яблочко. Если кто-то не может написать ясный код, разве ему удастся написать ясные комментарии? Кроме того, комментарии устаревают при изменениях кода.
Доверяя устаревшим комментариям, ты сам себе роешь яму.

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

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

Конструирование ПО

Что такое конструирование ПО?

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

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

Создал блог после опроса, готовлю статьи-конспекты «Совершенного кода» Макконнелла.

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

Присоединяйтесь, читайте, пишите!