• Романом Павленко
• Денисом “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;
	}
 
}

Самым полезным, для меня, оказался инструмент 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, позволяет оценить насколько ваш код соответствует стандартам кодирования.

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

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

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

В моем примере фабрики мы имеем три вида игровых юнитов 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

На диаграмме Приспособленец, выглядит следующим образом:

Имеет использовать Приспособленца если одновременно выполняются следующие условия:

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

Код примера:

 
class Wall:
 
    def draw(self):
        return "#"
 
class Floor:
 
    def draw(self):
        return "."
 
class MapFactory:
 
    def __init__(self):
        self.classes = (Floor(), Wall())
 
    def getMapClassByNum(self, num):
        return self.classes[num]
 
if __name__ == '__main__':
    map = """
111101111111
100000000001
100011110011
101000010001
111111111101"""
 
    factory = MapFactory()
    for line in map.split("\n")[1:]:
        for i in line:
            print(factory.getMapClassByNum(int(i)).draw()),
        print("")
 
--------------------------------
 
# # # # . # # # # # # #
# . . . . . . . . . . #
# . . . # # # # . . # #
# . # . . . . # . . . #
# # # # # # # # # # . #
 

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

На диаграмме Декоратор выглядит так:

Пример реализации паттерна Декоратор:

 
class BaseModel():
 
    def __init__(self):
        self.features = {"speakers":4, "airbag": 1, "engine": "1.2L"}
 
    def getPrice(self):
        return 12000
 
class AmbientModel():
 
    def __init__(self, model):
        self.price = model.getPrice() + 2200
        self.features = model.features
        self.features["airbag"] = 2
        self.features["speakers"] = 6
        self.features.setdefault("ligh", "halogen")
 
    def getPrice(self):
        return self.price
 
class SportModel(BaseModel):
 
    def __init__(self, model):
        self.price = model.getPrice() + 3800
        self.features = model.features
        self.features["airbag"] = 4
        self.features["engine"] = "1.6L"
 
    def getPrice(self):
        return self.price
 
class Auto:
 
    def __init__(self, model):
        self.model = model
 
    def specification(self):
        for i in self.model.features.keys():
            print("%-10s: %s" % (i, self.model.features[i]))
        print(("price     : %d") % self.model.getPrice())
 
if __name__ == '__main__':
    model = BaseModel()
    model = AmbientModel(model)
    model = SportModel(model)
    auto = Auto(model)
    auto.specification()
 
-------------------
 
airbag    : 4
engine    : 1.6L
speakers  : 6
ligh      : halogen
price     : 18000
 

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

Диаграмма для Компоновщика, выглядит так:

Реализовывая Компоновщик, нужно помнить о том чтобы интерфейс Component был максимально дополнен используемыми публичными методами, избавляя клиента от приведения к типу или проверки существования метода (в случае скриптовых языков). Также? стоит сразу позаботиться о максимально удобном функционале для управления элементами (помимо стандартных Add, Remove, GetChildIn).

Пример реализации на Python:

 
class TreeItem:
 
    def __init__(self, name):
        self.items = []
        self.name = name
        self.current = 0
 
    def __iter__(self):
        return self
 
    def add(self, item):
        self.items.append(item)
        return item
 
    def remove(self, name):
        self.items = [i for i in self.items if i.name != name]
 
    def __len__(self):
        return len(self.items)
 
    def get(self, i):
        return self.items[i]
 
    def next(self):
        self.current += 1
        if len(self.items) >= self.current:
            return self.items[self.current-1]
        else:
            raise StopIteration
 
if __name__ == '__main__':
    root = TreeItem('/')
    root.add(TreeItem("folder1"))
 
    print root.get(0).name
    root.remove("folder1")
 
    root.add(TreeItem("folder2")).add(TreeItem("folder21"))
    root.add(TreeItem("folder3")).add(TreeItem("folder31").add(TreeItem("folder311")))
 
    def walk(item, level):
        for i in range(level):
            print(" "),
        print(item.name)
        for i in item:
            walk(i, level + 1)
 
    walk(root, 0)
 
-----------------------------
folder1
/
  folder2
    folder21
  folder3
    folder311
 

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

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

Пример реализации паттарна Мост на Python:

 
class SortAbstraction:    
 
    def sortImpl(self, sortImpl):
        self._sortImpl = sortImpl
 
    def sort(self, data):
        self._sortImpl.sort(data)
        return data 
 
class SortImpl:
 
    def sort(self, data):
        pass
 
class FastSortimpl(SortImpl):
 
    def sort(self, data):
        return data.sort()
 
class SlowSortImpl(SortImpl):
 
    def sort(self, data):
        return data.sort() # медленная сортировка
 
class FastSortImpl(SortImpl):
 
    def sort(self, data):
        return data.sort() # якобы быстрая сортировка
 
if __name__ == '__main__':
    abstraction = SortAbstraction()
    abstraction.sortImpl(SlowSortImpl())
    print(abstraction.sort([2,1,3]))
 
    abstraction.sortImpl(FastSortImpl())
    print(abstraction.sort([2,1,3]))
 
-------------------------
[1, 2, 3]
[1, 2, 3]
 

Идея состоит в том что мы выбираем несколько паттернов, делаем лаконичный пример использования, на каком-то языке не связанной с основной работой (php). Затем мы собираемся, показываем свои примеры, и обсуждаем конкретный паттерн и реализацию. Так у нас накопилось некоторое количество реализаций на Python, Ruby, Groovy. На самом деле, как мы потом убедились, выбор скриптового языка для иллюстрации паттерна, идея не очень хорошая, — нельзя выделить интерфейс, абстрактный класс, вследствие отсутствия строгой типизации смысл некоторых паттернов теряется, некоторые патерны трудно отличить один от другого. Наверное в дальнейшем мы ограничимся языками со строгой типизацией для паттернов, а скриптовые будем использовать для иллюстрации алгоритмов. Время покажет.

После столь долгого вступления, расскажу о первом паттерне Адаптер и примере его реализации на питоне. Этот паттерн относится к структурным паттернам (structural). Вот как он выглядит на диаграмме классов:

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

Код примера реализации паттерна:

 
class SlowDbEngine:
 
    def __init__(self, host, user, password, db):
        pass
 
    def runQuery(self, sql):
        return ["row1", "row2", "row3"]
 
class FastDbEngine:
 
    def __init__(self, connection):
        pass        
 
    def query(self, sql):
        return range(3, 0, -1)
 
    def fetch(self, result):
        return "row%d" % (result.pop())
 
    def recordsCount(self, result):
        return len(result)
 
class DbAdapter:
 
    def __init__(self, host, user, password, db, type = "fast"):
        self._type = type
        if(type == "slow"):
            self._db = SlowDbEngine(host, user, password, db)
        else:
            self._db = FastDbEngine([host, user, password, db])
 
    def runQuery(self, sql):
        if self._type == "slow":
            return self._db.runQuery(sql)
        else:
            result = self._db.query(sql)
            return [self._db.fetch(result) for i in xrange(self._db.recordsCount(result))]
 
if __name__ == '__main__':
    print(DbAdapter("localhost", "root", "password", "db").runQuery("select * from table"))
 
-----------------------
 
['row1', 'row2', 'row3']
 

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

Поговорим немного о достоинствах платформы:

• в первую очередь, это, конечно масштабируемость «из коробки», о которой абсолютно не надо заботится. Гарантированный uptime 99.9%, никаких бекапов, репликаций и прочих мук в высоконагруженых приложениях.
• все разработчики, как один, восхищаются тем как хорошо документирован GAE, и тем как просто сделать свой первых hello world
• прозрачная интеграция с аккаунтом Google и многочисленными сервисами
• поддержка Java и Python «из коробки» и огромное количество скриптовых языком «из под Java»
• удобный сервер для разработки и простая утилита деплоя
• огромное количество open source проектов являются хорошим подспорьем в разработке на GAE

Как обычно в бочке меда, окажется ложка дегтя.

• ограничеие на размер файла: 1 мегабайт
• еще одно интересное ограничение, — на запрос, не более миллиона циклов CPU на запрос. У вас нет никакких инсрументов, позволяющих оценить, профилировать эти самые циклы, и на локальном сервере этого ограничения нет. Таким образом, приготовьтесь к тому что ваше сложное приложение начнет разваливаться после деплоя, вероятно, случайным образом.
• очень медленное локальное хранилище даных, хотя на сервере, после деплоя работа с хранилищем тоже неоднозначна, плюс на работу с хранилищем также налагаются ограничения и квоты
• загрузчик (bulk uploader) довольно медленный и часто генерирует 500ю ошибку.
• надо ли говорить — но у вас нет рутовых прав
• подробнее про ограничения можно почитать здесь

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

Некоторые выводы, о том как использовать GAE более эффективно:

• переносите логику и функционал на клиент, — всякого рода логика на JS, Flash, Flex, Silverlight, etc
• используйте memcache для кеширования запросов к хранилищу
• используйте sharded counters для статистики
• отсылка писем забирает много CPU, лучше использовать tasks или cron
• используйте несколько GAE приложений, для разных нужд, вместо одного большого. Это имеет смысл для увеличения квот и разделения статистики.
• используйте пакетное сохранение и извлечение данных из хранилища