Вопрос был о том, насколько актуальна сегодня парадигма ООП, и что ждет программирование дальше. Сергей ссылался на интересное обсуждение здесь. Из комментариев этого обсуждения можно видеть, насколько тема неоднозначна и противоречива. Я, ни в коем случае не считаю себя большим экспертом в этой области, но есть некоторые мысли, которыми хочу поделиться, надеюсь это будет интересно, ведь недаром, спору «нужен ли C++» уже почти пол века.

Первое, о чем хочется упомянуть, это ни функциональные языки программирования, ни DSL, не являются чем-либо новым, равно как и многие другие «новые подходы», вновь ставшие популярными последние годы. Многие из них берут начало в 60х годах, когда программистов было мало, и пришли они, в основном, из среды математиков и физиков. Тогда было легко изобретать новое, и это быстро подхватывалось пытливыми умами, развивалось и применялось. Сейчас количество программистов значительно выросло, и как следствие, уровень среднего программиста стал значительно ниже. Программирование проделало длинный путь от искусства и науки к ремеслу. Программистская среда стала более инертной, с трудом принимая новые подходы, и чем сложнее подход, тем менее он популярен. Именно поэтому, уже завоевавшая популярность, несложная концепция объектного проектирования по-прежнему остается такой востребованной. Несколько слов в защиту ООП, — во-первых, это работает. Так или иначе, программисты научились понимать друг-друга, строить сложные системы и создавать абстракции при помощи паттернов. Множество программистов начало думать в терминах ООП, множество кода написано и протестировано. Это то, что делает ООП актуальным еще долгое время, особенно для решения классических задач. Но для задач нетривиальных, всегда необходимо пробовать и применять новые подходы. «Серебряной пули» не существует. Более того, понимание подходов функционального программирования, макроязыков, алгоритмов, устройства компиляторов-интерпретаторов дают программисту неоспоримые преимущества для написание качественного и гибкого кода. Поэтому изучайте, пробуйте, и эти знания изменят ваш код и подходы к работе.

Несколько слов о том, как я вижу развитие программирования:

• Я думаю что постепенно программирование будет смещаться от императивных языков к декларативным. Я имею ввиду, что человек не будет фокусироваться на пути реализации, не будет описывать «как делать», а лишь, «что должно получиться». Профессия программиста трансформируется, — будут своего рода аналитики, описывающие требования к системе, на основании которых система будет работать, без всякого дополнительного кодирования.
• В связи с тем, что развитие современных процессоров вступило в фазу экстенсивного развития (от гонки частот мы переходим к гонке количества ядер), скоро мы должны увидеть взлет популярности простого функционального языка, к сожалению это не будет ни haskel и erlang, а вероятнее всего javascript. Хотя тут, очень легко ошибиться.
• Еще раньше, я думаю, мы увидим то, как средства визуального проектирования вновь войдут в моду. С одной стороны, это немного противоречит «декларативной природе», с другой — я думаю нам еще долго не удастся настолько специфицировать интерфейсы, чтобы стало возможным генерировать их.
• Интерфейсы взаимодействия пользователя с системой будут стандартизироваться все больше и больше. Роль дизайна будет решающей, и попытки специфицировать UI будут способствовать как обучению пользователей взаимодействовать с системами, так и проектировщиков, строить их максимально предсказуемо.

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

 
class QueryIter():
 
    _limit_fetch = 1000
    _items = None
    _cursor = None
    _debug_limit = 10000
 
    def __init__(self, query):
        self._query = query
        self._fetchNext()        
 
    def _fetchNext(self):
        self._items = iter(self._query.fetch(self._limit_fetch))
        self._cursor = self._query.cursor()        
 
    def __iter__(self):
        return self
 
    def next(self):
        self._debug_limit -= 1
        if self._debug_limit < = 0:
            raise StopIteration
        else:
            try:
                result = self._items.next()
            except StopIteration, e:
                self._query.with_cursor(self._cursor)
                self._fetchNext()
                result = self._items.next() # raised exception stop the loop
            return result

А вот, пример применения:

query = MyModel.all()
for i in QueryIter(query):
    print i

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

 
from google.appengine.api import users
 
import os
import wsgiref.handlers
 
import cgi
import datetime
import httplib
import time
 
from google.appengine.api.labs import taskqueue
from google.appengine.ext.webapp import template
from google.appengine.ext import db
from google.appengine.ext import webapp
from google.appengine.api import memcache
from google.appengine.api import mail
 
class MonitoringHandler(BaseHandler):    
 
    def get(self):
        today = datetime.datetime.now().strftime("%d-%m-%y %H:%M:%S")
        self.response.headers['Content-Type'] = 'text/plain'
        self.response.out.write(today)
        try:
            conn = httplib.HTTPSConnection("site.com", timeout=1000)
            conn.request("GET", "/")
 
            if(conn.getresponse().read().find("some text string") < = 0):
                raise Exception("String not found")
            self.response.out.write(" Everything is ok")
        except Exception, e:
			self.response.out.write(" Send email")
			mail.send_mail(sender="from@email.com",
						  to="your@email.com",
						  subject="ServerFail",
						  body="[%s] %s" % (today, e))
 
if __name__ == '__main__':
    application = webapp.WSGIApplication(
        [
            ('/', MonitoringHandler)
        ], debug=True
    )
    wsgiref.handlers.CGIHandler().run(application)
 

• Романом Павленко
• Денисом “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 XMPPRequest():
 
    def __init__(self, connect):
        pass
 
    def send(self, to, text):
        return True
 
class XmppProxy():
 
    def send(self, who, to, text):
        xmpp = XMPPRequest(who)
        return xmpp.send(to, text)
 
if __name__ == '__main__':
    proxy = XmppProxy()
    print(proxy.send("mrjazz", "team", "hi all"))

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

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

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

Код примера:

 
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