• Подборка ссылок на прошлогодние мысли Макса Крайнова. Что самое интересное, по прежнему не утратившие своей актуальности и полезности.
• Один и второй выпуски подкаста «The Art Of Programming» с участием Константина Ковалева, в которых он, своим трезвым и рассудительным взглядом, смотрит на платформу Adobe Flash, её прошлое, настоящее и будущее.
• Несколько ссылок для тех кто посматривает в сторону mercurial в качестве системы контроля версий: набор шпаргалок, красиво иллюстрированное введение в распределенные системы хранения версий на примере mercurial и качественный сайт про переход на mercurial от самого Джоэля Спольски.
• Хорошая статейка о распространенной проблеме управления в наших гос учереждениях. К счастью в IT встречается не так часто, но знать об этом, безусловно надо.
• В facebook появилось приложение от adobe с помощью которого, можно с удовольствием проверить свой уровень знаний по Flex

• Романом Павленко
• Денисом “Barmaleychik” Волохом
• Дмитрием “Reijii” Кочетовым
• Ростиславом “RostislavR” Сирыком

cделали перевод документации к PureMVC а Клифф Холл опубликовал.

Со временем в переводе было найдено массу огрехов, благодаря читателям flash-ripper.com но обновленный документ развалил нам структуру вордовского документа, который Клифф использует для конвертации документации в pdf, и окончательно опустив руки в борьбе с Microsoft Word исправленный перевод был закинут в долгий ящик. Недавно, разгребая завалы неоконченных дел, я нашел этот документ и решил опубликовать его хотя бы в блоге, - надеюсь ищущие найдут его тут.

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

1. Cортировку вставками (Insertion sort), сортирующую за конечное время и эффективному при небольших массивах, а также с частично отсортированными массивами
2. Быструю сортировку (Quicksort), сортирующую быстрее, но требующую O(log n) дополнительной памяти
3. Сортировку подсчетом (Counting sort), эффективный для большого количества данных с небольшим разбросом значений

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

Вот как паттерн Стратегия, выглядит на UML диаграмме:

А вот пример на языке java, из уже классической, игровой тематики:

// IUnitRender.java
package patterns.strategy;
 
public interface IUnitRender {
 
	public void render();
 
}
 
// UnitRender2D.java
package patterns.strategy;
 
public class UnitRender2D implements IUnitRender {
 
	@Override
	public void render() {
		System.out.println("2D unit");
	}
 
}
 
// UnitRender3D.java
package patterns.strategy;
 
public class UnitRender3D implements IUnitRender {
 
	@Override
	public void render() {
		System.out.println("3D unit");
	}
 
}
 
// UnitSprite
package patterns.strategy;
 
public class UnitSprite {
 
	private IUnitRender render;
 
	public UnitSprite(IUnitRender render) {
		this.render = render;
	}
 
	public void render() {
		render.render();
	}
 
}
 
// TestApp.java
package patterns.strategy;
 
public class TestApp {
 
	public static void main(String[] args) {
		UnitSprite unit;
 
		if(TestApp.hasVideoAdapter()) {
			unit = new UnitSprite(new UnitRender3D());
		} else {
			unit = new UnitSprite(new UnitRender2D());
		}
 
		unit.render();
	}
 
	public static Boolean hasVideoAdapter() {
		return true;
	}
 
}

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

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

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

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

Неумение слушать и говорить

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

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

Проверьте себя. Если вы не согласны (полностью или частично) с утверждениями:

Другие люди совсем не такие, как я. Их интересует не то, что интересует меня. Они мыслят иначе, чем я. Они знают то, что я не знаю. Они оценивают события по критериям, которые мне не известны и чужды.

...у вас, по всей видимости, проблемы с эмпатией. Придя на интервью с заказчиком, вы, скорее всего, слышите себя (а не заказчика), поскольку у вас нет стимула узнать что-то о другом человеке (я предполагаю, что для того, чтобы что-то узнать, нужно сначала признать, что это что-то ещё неизвестно). Это преодолимо, нужно всего лишь регулярно и методично напоминать себе, что другие люди — именно что другие. Кроме того, великолепно помогает тренировке эмпатии присутствие при юзабилити-тестировании своего интерфейса (можно смотреть записи его же; даже записи тестов чужих интерфейсов неплохо помогают тренировать эмпатию).

Отсутствие вкуса

Чтобы появилось само понятие красивого человека, большинство людей должно быть некрасивыми. Это же верно и для вкуса, с той только поправкой, что красота во многом есть свойство врождённое,
а вкус — всегда приобретённый, никто не рождается с развитым чувством прекрасного. Его развитие занимает годы, и эти годы не просто надо прожить, но тратить время и усилия на развитие своего
вкуса.

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

Проверьте себя. Если вы:

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

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

Неумение писать

Мысли имеют неприятное обыкновение из чётких и ясных становиться неоднозначными и неполными (а зачастую и самопротиворечивыми), стоит их только записать. Объясняется это просто — пока они ещё в
голове, многие выводы, не говоря уж о противоречиях, попросту не видны. На бумаге же проблемы проступают немедленно.

Согласно Федору Тютчеву, мысль изречённая есть ложь. Мысль записанная тоже может быть ложью, но ложь эта, по крайней мере, не гарантированная, как в случае мысли высказанной.

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

Проверьте себя. В 2000 знаков опишите, что вы видите вокруг в этот самый момент, отмечая самое замечательное в том, что вы видите. Покажите текст кому-нибудь, кто, по вашему мнению, хорошо «знает
русского языка». Если задание далось вам с большим трудом или знаток языка раскритиковал его в пух и прах, поздравляю — вы не писатель. Купите пару книг по редактуре (см. раздел Рекомендуемая литература) и практикуйтесь до посинения. Лично я научился хоть как-то писать только после семисот тысяч написанных знаков.

Проблемы с логикой

Чтобы были умные люди, большинство должно быть глупыми. Но ум, как и глупость, понятие растяжимое. Меня сейчас интересует только один сорт глупости, а именно неумение рассуждать о чем-то скучном продолжительное время.

Например, поиск в интерфейсе исключительных ситуаций (предпосылок для ошибок, как системных, так и человеческих) — совершенно необходимая стадия дизайна. Чисто технически — это очень продол-
жительное рассуждение, при котором дизайнер последовательно перебирает все объекты и состояния интерфейса в поиске возможных несоответствий («так, а что будет, если пользователь нажмёт кнопку
поиска, не введя ничего в поле ввода?»). Многие люди (в том числе большинство т.н. гуманитариев) сталкиваются в этой работе с большими трудностями — нетренированному мозгу это очень тяжело и
утомительно. Конечно, практика тренирует мозг очень быстро, но, поскольку эта работа такова, что её можно «задвинуть», отфутболив программисту, практики не получается. Отсюда — невозможность
профессионального роста.

Проверьте себя. Найдите какую-нибудь книгу логических задач (особо рекомендую книги Раймонда Смаллиана) и попробуйте решать их, не отвлекаясь, не менее полутора часов подряд. Если дело не идет — найдите ещё десяток таких книг и решайте, решайте, решайте. Интеллектуальный марафон не повредит.

Отсутствие профессионального любопытства

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

• не знаете, кто такие Джозайа Веджвуд и Раймонд Лоуи
• не знаете, что такое интерлиньяж
• не можете перечислить хотя бы пять интерфейсных решений, которые в Windows лучше по сравнению с MacOS (и обратно)

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

Что делать?

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

Если по роду работы сталкиваетесь с пользовательскими интерфейсами и у вас обнаружились пробелы, надеюсь это подтолкнет вас к тому, чтобы найти хорошего специалиста которому можно поручить столь важный этап в работы, либо подтолкнет к самообучению и даже, возможно вы начнете с книги a href="http://uibook2.usethics.ru/">"Дизайн пользовательского интерфейса² Искусство мыть слона". Ну а если у вас никаких пробелов не обнаружилось, то знайте, мне очень приятно что вы посетили мой сайт.

Самым полезным, для меня, оказался инструмент Copy/Paste Detector for PHP code. Как ясно из названия, этот инструмент используется для дублирующегося кода, ярым поборником которого я являюсь.

Устанавливается он очень просто, как PEAR пакет:

sb@ubuntu ~ % pear channel-discover pear.phpunit.de
Adding Channel "pear.phpunit.de" succeeded
Discovery of channel "pear.phpunit.de" succeeded

sb@ubuntu ~ % pear channel-discover components.ez.no
Adding Channel "components.ez.no" succeeded
Discovery of channel "components.ez.no" succeeded

sb@ubuntu ~ % pear install phpunit/phpcpd
downloading phpcpd-1.3.0.tgz ...
Starting to download phpcpd-1.3.0.tgz (7,809 bytes)
.....done: 7,809 bytes
downloading File_Iterator-1.1.0.tgz ...
Starting to download File_Iterator-1.1.0.tgz (3,181 bytes)
...done: 3,181 bytes
downloading ConsoleTools-1.6.tgz ...
Starting to download ConsoleTools-1.6.tgz (869,925 bytes)
.........................................................
.........................................................
.........................................................
..done: 869,925 bytes
downloading Base-1.8.tgz ...
Starting to download Base-1.8.tgz (236,357 bytes)
...done: 236,357 bytes
install ok: channel://components.ez.no/Base-1.8
install ok: channel://components.ez.no/ConsoleTools-1.6
install ok: channel://pear.phpunit.de/File_Iterator-1
install ok: channel://pear.phpunit.de/phpcpd-1.3.0

Пользоваться, тоже, — очень просто:

bash-3.2# phpcpd PEAR/tests/
phpcpd 1.3.1 by Sebastian Bergmann.

Found 5 exact clones with 85 duplicated lines in 5 files:

  - MDB2/tests/MDB2_extended_testcase.php:398-404
    MDB2/tests/MDB2_extended_testcase.php:453-459

  - MDB2/tests/MDB2_manager_testcase.php:61-75
    MDB2/tests/MDB2_reverse_testcase.php:86-100

  - MDB2/tests/MDB2_usage_testcase.php:1289-1321
    MDB2/tests/MDB2_usage_testcase.php:1577-1609

  - MDB2/tests/MDB2_usage_testcase.php:1567-1593
    MDB2/tests/MDB2_usage_testcase.php:1739-1765

  - Structures_Graph/tests/testCase/BasicGraph.php:111-118
    Structures_Graph/tests/testCase/BasicGraph.php:142-149

Еще один полезный инструмент, это PHP Depend. Он позволяет взглянуть на ваш проект, как бы, с «высоты птичьего полета», предоставляя такие метрики как: количество строк кода, классов, пакетов, методов, вызовов и даже эмпирическую метрику «сложность кода». Здесь можно прочитать расшифровку всех показателей.

Я сравнил два довольно больших проекта, которые веду и метрики отразили в цифрах почти то же что и было «по ощущению», — более новый проект проще и лучше приблизительно в 2-3 раза, при том что имеет более сложную бизнес логику и функционал:

Следующий, хороший инструмент это PHP Mess detector. Устанавливается он аналогично, с помощью PEAR installer:

mapi@arwen ~ $ pear channel-discover pear.phpmd.org
mapi@arwen ~ $ pear channel-discover pear.pdepend.org
mapi@arwen ~ $ pear install --alldeps phpmd/PHP_PMD-alpha

Эта утилита дает нам массу интересной информации для размышления:

bash-3.2# phpmd PEAR/Pear.php text codesize

PEAR.php:87	This class has a bunch of public methods and attributes
PEAR.php:87	This class has too many methods, consider refactoring it.
PEAR.php:87	This class PEAR has an overall complexity of 102 which is very high. The configured complexity threshold is 50.
PEAR.php:323	The method setErrorHandling() has a Cyclomatic Complexity of 11.
PEAR.php:511	The method raiseError() has a Cyclomatic Complexity of 20.
PEAR.php:511	The method raiseError() has an NPath complexity of 1600.
PEAR.php:771	The function _PEAR_call_destructors() has a Cyclomatic Complexity of 12.
PEAR.php:831	This class has a bunch of public methods and attributes
PEAR.php:866	The method PEAR_Error() has a Cyclomatic Complexity of 19.
PEAR.php:866	The method PEAR_Error() has an NPath complexity of 11520.

bash-3.2# phpmd PEAR/Pear.php text unusedcode

PEAR.php:450	Avoid unused local variables such as '$key'.
PEAR.php:788	Avoid unused local variables such as '$k'.

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

Похожий по своему применению инструмент PHP_CodeSniffer, позволяет оценить насколько ваш код соответствует стандартам кодирования.

Пример применения паттерна на UML диаграмме:

А вот, пример применения паттерна в коде, - класс создающий разные типы документов, из одинаковых составных частей:

// IChapter.java
package patterns.factorymethod.report;
 
public interface IChapter {
 
	public String getType();
 
}
 
// IReport.java
package patterns.factorymethod.report;
 
public interface IReport {
 
	public void render();
	public void addChapter(IChapter chapter);	
 
}
 
// CustomReport.java
package patterns.factorymethod.report;
 
import java.util.ArrayList;
import java.util.Iterator;
 
public class CustomReport implements IReport {	
 
	protected ArrayList<IChapter> chapters = new ArrayList<IChapter>();	
 
	@Override
	public void render() {
		for (Iterator<IChapter> iter = chapters.iterator(); iter.hasNext();  ) {
			System.out.println(((IChapter)iter.next()).getType());
		}
	}
 
	@Override
	public void addChapter(IChapter chapter) {
		chapters.add(chapter);
	}
 
}
 
// ExtendedChapter.java
package patterns.factorymethod.report;
 
public class ExtendedChapter implements IChapter {
 
	@Override
	public String getType() {
		return "Extended";
	}
 
}
 
//  IndexChapter.java
package patterns.factorymethod.report;
 
public class IndexChapter implements IChapter {
 
	@Override
	public String getType() {
		return "Index";
	}
 
}
 
// SmallChapter.java
package patterns.factorymethod.report;
 
public class SmallChapter implements IChapter {
 
	@Override
	public String getType() {
		return "Small";
	}
 
}
 
// TitleChapter.java
package patterns.factorymethod.report;
 
public class TitleChapter implements IChapter {
 
	@Override
	public String getType() {
		return "Title";
	}
 
}
 
// ReportCreator.java
package patterns.factorymethod.report;
 
public class ReportCreator {
 
	public IReport createSummaryReport() {
		CustomReport report = new CustomReport();
		report.addChapter(new TitleChapter());
		report.addChapter(new SmallChapter());
		return report;
	}
 
	public IReport createFullReport() {
		CustomReport report = new CustomReport();
		report.addChapter(new TitleChapter());
		report.addChapter(new IndexChapter());
		report.addChapter(new ExtendedChapter());
		return report;
	}
 
}
 
// TestApp.java
package patterns.factorymethod;
 
import patterns.factorymethod.report.ReportCreator;
 
public class TestApp {
 
	public static void main(String[] args) {
		ReportCreator creator = new ReportCreator();
		creator.createFullReport().render();
		System.out.println();
		creator.createSummaryReport().render();
	}
 
}

Результат работы программы:

Title
Index
Extended

Title
Small

Паттерн абстрактная фабрика должен использоваться тогда когда:

• Конкретный вариант требуемого поведения системы дают не отдельные объекты, а четко выраженное семейство связанных объектов
• Объекты одного семейства должны использоваться вместе
• Система должна кофигурироваться одним из семейств объектов

Вот как это выглядит на диаграмме:

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

// IUnit.java
package patterns.factory.unit;
 
public interface IUnit {
 
	public int getGroundWeapon();
	public int getAirWeapon();
	public int getShield();
	public int getPrice();
	public String toString();
 
}
 
// CustomUnit.java
package patterns.factory.unit;
 
public class CustomUnit implements IUnit {
 
	@Override
	public int getAirWeapon() {
		return 0;
	}
 
	@Override
	public int getGroundWeapon() {
		return 0;
	}
 
	@Override
	public int getPrice() {
		return 0;
	}
 
	@Override
	public int getShield() {
		return 0;
	}
 
	public String toString() {
		return "a:" + getAirWeapon() + " g:" + getGroundWeapon() + " s:" + getShield() + " p:" + getPrice();
	}
 
}
 
// ProtosSoldier.java
package patterns.factory.unit;
 
public class ProtosSoldier extends CustomUnit implements IUnit {
 
	@Override
	public int getAirWeapon() {
		return 10;
	}
 
	@Override
	public int getGroundWeapon() {
		return 12;
	}
 
	@Override
	public int getPrice() {
		return 100;
	}
 
	@Override
	public int getShield() {
		return 10;
	}
 
}
 
// Terransoldier.java
package patterns.factory.unit;
 
public class TerranSoldier extends CustomUnit implements IUnit {
 
	@Override
	public int getPrice() {
		return 35;
	}
 
	@Override
	public int getAirWeapon() {
		return 5;
	}
 
	@Override
	public int getGroundWeapon() {
		return 8;
	}
 
	@Override
	public int getShield() {
		return 3;
	}
 
}
 
// ZergSoldier.java
package patterns.factory.unit;
 
public class ZergSoldier extends CustomUnit implements IUnit {
 
	@Override
	public int getAirWeapon() {
		return 0;
	}
 
	@Override
	public int getGroundWeapon() {
		return 6;
	}
 
	@Override
	public int getPrice() {
		return 25;
	}
 
	@Override
	public int getShield() {
		return 5;
	}
 
}
 
// IArmyFactory.java
package patterns.factory.army;
 
import patterns.factory.unit.IUnit;
 
public interface IArmyFactory {
 
	public IUnit createSoldier();
 
}
 
// ProtosArmy.java
package patterns.factory.army;
 
import patterns.factory.unit.IUnit;
import patterns.factory.unit.ProtosSoldier;
 
public class ProtosArmy implements IArmyFactory {
 
	@Override
	public IUnit createSoldier() {
		return new ProtosSoldier();
	}
 
}
 
// TerranArmy.java
package patterns.factory.army;
 
import patterns.factory.unit.IUnit;
import patterns.factory.unit.TerranSoldier;
 
public class TerranArmy implements IArmyFactory {
 
	@Override
	public IUnit createSoldier() {
		return new TerranSoldier();
	}
 
}
 
// ZergArmy.java
package patterns.factory.army;
 
import patterns.factory.unit.IUnit;
import patterns.factory.unit.ZergSoldier;
 
public class ZergArmy implements IArmyFactory {
 
	@Override
	public IUnit createSoldier() {
		return new ZergSoldier();
	}
 
}
 
// BotClient.java
package patterns.factory.client;
 
import java.util.ArrayList;
import java.util.Iterator;
 
import patterns.factory.army.IArmyFactory;
import patterns.factory.unit.IUnit;
 
public class BotClient {
 
	private ArrayList <IUnit> units;
	private IArmyFactory factory;
 
	public BotClient(IArmyFactory army) {
		factory = army;
		units = new ArrayList <IUnit> ();
	}
 
	public void createForMoney(int money) {
		Boolean hasMoney = false;
		units.clear();
		do {
			IUnit unit = factory.createSoldier();
			hasMoney = money - unit.getPrice() > 0;
			if(hasMoney){
				units.add(unit);
				money -= unit.getPrice();
			}
		} while(hasMoney);
	}
 
	public int getGroundWeapon() {
		int total = 0;
		Iterator  iter = units.iterator();
	    while (iter.hasNext()) {
	    	total += ((IUnit)iter.next()).getGroundWeapon();
	    }
	    return total;
	}
 
	public int getShield() {
		int total = 0;
		Iterator  iter = units.iterator();
	    while (iter.hasNext()) {
	    	total += ((IUnit)iter.next()).getShield();
	    }
	    return total;
	}
 
	public int unitsCount() {
		return units.size();
	}
 
	public Boolean battle(BotClient client) {
		System.out.println("Units: " + unitsCount() + " vs " + client.unitsCount());
		System.out.println("Attack: " + getGroundWeapon() + " vs " + client.getGroundWeapon());
		System.out.println("Shield: " + getShield() + " vs " + client.getShield());
		float damage = (float)client.getGroundWeapon() / (float)getShield();
		System.out.println("Damage: " + damage);
		float enemyDamage = (float)getGroundWeapon() / (float)client.getShield();
		System.out.println("Enemy damage: " + enemyDamage);
		return enemyDamage < damage;
	}
 
}
 
// TestApp.java
package patterns.factory;
 
import patterns.factory.army.ProtosArmy;
import patterns.factory.army.TerranArmy;
import patterns.factory.army.ZergArmy;
import patterns.factory.client.BotClient;
 
public class TestApp {
 
	public static void main(String[] args) {
		BotClient bot1 = new BotClient(new ProtosArmy());
		BotClient bot2 = new BotClient(new TerranArmy());
		BotClient bot3 = new BotClient(new ZergArmy());
		bot1.createForMoney(400);
		bot2.createForMoney(400);
		bot3.createForMoney(400);
		System.out.println(bot1.battle(bot2));
		System.out.println(bot1.battle(bot3));
	}
 
}

Результат работы примера:

Units: 3 vs 11
Attack: 36 vs 88
Shield: 30 vs 33
Damage: 2.9333334
Enemy damage: 1.0909091
false
Units: 3 vs 15
Attack: 36 vs 90
Shield: 30 vs 75
Damage: 3.0
Enemy damage: 0.48
false

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

Вот как это выглядит в UML:

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

 
 
// IPlace.java
 
package patterns.builder.map;
 
public interface IPlace {
 
	public String render();
 
}
 
// FloorPlace.java
 
package patterns.builder.map;
 
public class FloorPlace implements IPlace {
 
	@Override
	public String render() {
		return ".";
	}
 
}
 
// WallPlace.java
 
package patterns.builder.map;
 
public class WallPlace implements IPlace {
 
	@Override
	public String render() {
		return "#";
	}
 
}
 
// World.java
 
package patterns.builder.map;
 
public class World {
 
	private IPlace[][] places;
	private int WIDTH;
	private int HEIGHT;
 
	public World(int width, int height) {
		WIDTH = width;
		HEIGHT = height;
		places = new IPlace[WIDTH][HEIGHT];
	}
 
	public int getWidth() {
		return WIDTH;
	}
 
	public int getHeight() {
		return HEIGHT;
	}
 
	public void setPlace(int x, int y, IPlace place) {
		places[x][y] = place;
	}
 
	public void render() {
		for(int y = 0; y < HEIGHT; y++) {
			for(int x = 0; x < WIDTH; x++) {
				System.out.print(places[x][y].render());
			}
			System.out.println();
		}
	}
 
}
 
// WorldBuilder.java
 
package patterns.builder.map;
 
public class WorldBuilder {
 
	private World world;
 
	public WorldBuilder(World world) {
		this.world = world;
	}
 
	public void createFloorAt(int x, int y) {
		world.setPlace(x, y, new FloorPlace());
	}
 
	public void createWallAt(int x, int y) {
		world.setPlace(x, y, new WallPlace());
	}
 
	public void createEmptyWorld() {
		for(int y = 0; y < world.getHeight(); y++) {
			for(int x = 0; x < world.getWidth(); x++) {
				createFloorAt(x, y);
			}
		}
	}
 
	public void createRandomWorld(int emptynessRatio) {
		for(int y = 0; y < world.getHeight(); y++) {
			for(int x = 0; x < world.getWidth(); x++) {
				if(Math.round(Math.random() * 100) < emptynessRatio){
					createFloorAt(x, y);
				} else {
					createWallAt(x, y);
				}
			}
		}
	}
 
}
 
// TestApp.java
 
package patterns.builder;
 
import patterns.builder.map.World;
import patterns.builder.map.WorldBuilder;
 
public class TestApp {
 
	/**
	 * @param args
	 */
	public static void main(String[] args) {
		World world = new World(20, 5);
		WorldBuilder builder = new WorldBuilder(world);
		builder.createEmptyWorld();
                      world.render();
		builder.createRandomWorld(90);
		world.render();
	}
 
}
 

А вот результат работы:

....................
....................
....................
....................
....................

...##......#........
.#..................
.......#.......#....
.......#..#.....#...
..##....#.....#.....

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

Вот UML диаграмма:

Классический пример это контекстная справка в Microsoft Office, вы можете нажать кнопку вопросительного знака и кликнуть на любом элементе интерфейса, а система попытается найти страницу справки, максимально соответствующую запрошенному элементу. Делается это следующим образом, — поскольку интерфейс системы иерархичен, то запрс справки начинает подниматься снизу вверх — от элемента по которому был произведен клик вверх, первый элемент который «возьмется дать ответ», и покажет справку.

В моем случае Цепочку Ответственности иллюстрирует класс игрового юнита, поведение к которому приближается вражеский ююнит, и в зависимости от игровой ситуации мы решаем как он поступит. Я определил несколько поведений: DefaultBehavoir (бызовый класс с общим функционалом), CarefulBehavoir (осторожность), AttackBehavoir (смелость), AngryBehavoir (злость). Мы можем выстроить иерархию поведения так как захотим (при этом верхнее поведение играет более важную роль при принятии решений).

Вот код примера:

// IBehavoir.java
 
package patterns.chain;
 
public interface IBehavoir {
 
	public int handle(int distance, int power);
 
}
 
// DefaultBehavoir.java
 
package patterns.chain;
 
public class DefaultBehavoir implements IBehavoir {
 
	static public int WAIT = 0;
	static public int ATTACK = 1;
	static public int RUN = 2;
 
	protected DefaultBehavoir behavoir;
	protected Unit unit;
 
	public DefaultBehavoir(Unit unit) {
		this.unit = unit;
	}
 
	public int handle(int distance, int power) {
		if(behavoir != null) {
			return behavoir.handle(distance, power);
		} else {
			System.out.println("DefaultBehavoir::handle()");
			return DefaultBehavoir.WAIT;
		}
	}
 
	public DefaultBehavoir addBehavoir(DefaultBehavoir behavoir) {
		this.behavoir = behavoir;
		return this;
	}	
 
	static public String getCode(int option) {
		switch(option) {
			case 1:
				return "attack!!!";
			case 2:
				return "run!";
			default:
				return "waiting...";
		}
	}
 
}
 
// CarefulBehavoir.java
 
package patterns.chain;
 
public class CarefulBehavoir extends DefaultBehavoir implements IBehavoir {
 
	public CarefulBehavoir(Unit unit) {
		super(unit);
	}
 
	public int handle(int distance, int power) {
		System.out.println("CarefulBehavoir::handle()");
		if(power < unit.getPower()) {
			if(distance < unit.getAttackDistance()) {
				return DefaultBehavoir.ATTACK;
			} else {
				return DefaultBehavoir.WAIT;
			}
		} else if((distance + 2 < unit.getAttackDistance()) && (power > unit.getPower()))  {
			return DefaultBehavoir.RUN;
		}
		return super.handle(distance, power);
	}	
 
}
 
// AttackBehavoir.java
 
package patterns.chain;
 
public class AttackBehavoir extends DefaultBehavoir implements IBehavoir {
 
	public AttackBehavoir(Unit unit) {
		super(unit);
	}
 
	public int handle(int distance, int power) {
		System.out.println("AttackBehavoir::handle()");
		if((distance < unit.getAttackDistance()) && (power < unit.getPower())) {
			return DefaultBehavoir.ATTACK;
		}
		return super.handle(distance, power);
	}
 
}
 
// AngryBehavoir.java
 
package patterns.chain;
 
public class AngryBehavoir extends DefaultBehavoir implements IBehavoir {
 
	public AngryBehavoir(Unit unit) {
		super(unit);
	}
 
	public int handle(int distance, int power) {
		System.out.println("AngryBehavoir::handle()");
		if((distance / 2 < unit.getAttackDistance()) && (power / 5 < unit.getPower())) {
			return DefaultBehavoir.ATTACK;
		}
		return super.handle(distance, power);
	}
 
}
 
// Unit.java
 
package patterns.chain;
 
public class Unit {
 
	protected int power;
	protected int attackDistance;
	private DefaultBehavoir behavoir;
 
	public Unit(int power, int attackDistance) {
		this.power = power;
		this.attackDistance = attackDistance;
	}
 
	public int getPower() {
		return power;
	}
 
	public int getAttackDistance() {
		return attackDistance;
	}
 
	protected void setBehavoir(DefaultBehavoir behavoir) {
		this.behavoir = behavoir;
	}
 
	protected DefaultBehavoir getBehavoir() {
		return behavoir;
	}
 
	public int processSituation(int distance, int power) {
		return behavoir.handle(distance, power);
	}	
 
}
 
// TestApp.java
 
package patterns.chain;
 
public class TestApp {
 
	/**
	 * @param args
	 */
	public static void main(String[] args) {
		Unit unit = new Unit(5,10);
		unit.setBehavoir(
			new CarefulBehavoir(unit).addBehavoir(
				new AttackBehavoir(unit).addBehavoir(
					new DefaultBehavoir(unit)
				)
			)
		);
		System.out.println(DefaultBehavoir.getCode(unit.processSituation(1,1)));
		System.out.println(DefaultBehavoir.getCode(unit.processSituation(5,10)));
		System.out.println(DefaultBehavoir.getCode(unit.processSituation(20,5)));
 
		unit.setBehavoir(
			new AngryBehavoir(unit).addBehavoir(
				new CarefulBehavoir(unit).addBehavoir(
					new DefaultBehavoir(unit)
				)
			)
		);
 
		System.out.println(DefaultBehavoir.getCode(unit.processSituation(1,1)));
		System.out.println(DefaultBehavoir.getCode(unit.processSituation(7,20)));
		System.out.println(DefaultBehavoir.getCode(unit.processSituation(20,5)));
 
	}
 
}

Вот результат работы программы:

CarefulBehavoir::handle()
attack!!!
CarefulBehavoir::handle()
run!
CarefulBehavoir::handle()
AttackBehavoir::handle()
DefaultBehavoir::handle()
waiting...
AngryBehavoir::handle()
attack!!!
AngryBehavoir::handle()
attack!!!
AngryBehavoir::handle()
CarefulBehavoir::handle()
DefaultBehavoir::handle()
waiting...

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