Insight IT

Основы Erlang: синтаксис и пунктуация

Иван Блинков — Fri, 22 Jun 2012 01:27:00 +0400

Мои теоретичесие рассуждения о месте Erlang в ~~современном мире~~ Интернете Вы можете почитать в отдельной статье. Если сомневаетесь интересно Вам это все или нет - то прочтите сначала её. Сегодня я постараюсь вернуться с небес на землю и пройтись по азам этого пугающего многих языка программирования. Коротко и по делу.

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

После установки в $PATH окажутся исполняемые файлы:

erl - одновременно интерактивная консоль и запуск приложений;
erlc - компилятор в байт-код для виртуальной машины BEAM или нативный код посредством HiPE, напрямую использовать не придется практически.

Со всем что будет обсуждаться в этой статье можно эксперементировать просто в интерактивной консоли, которая запускается просто командой erl без аргументов.

Пунктуация

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

Все функции заканчиваются точкой
После каждого выражения в функции - запятая;
Все ветви кода (case, if, ...), кроме последней, заканчиваются точкой с запятой
После заголовка функции и условий ветвления пишется стрелка ->

Маленькая демонстрация:

foo(X, Y) ->
  Z = X * X,
  if
    Y > 0 ->
      Z + Y;
    true ->
      Z - Y
  end.

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

Синтаксис

Foo - все что начинается с английской заглавной буквы - переменная, специально объявлять ничего не нужно
_ - сам знак нижнего подчеркивания и все что с него начинается - особый случай переменной, значение которой не значимо для программы и при первой возможности "выкидывается"
Цифры в основном как обычно, есть научная нотация в духе 1.23e4 (1.23 умножить на 10 в степени 4) и системы исчисления с другим основанием, скажем двоичная - 2#101010
foo - с строчной буквы начинаются атомы, по сути константы, используются повсеместно:
- названия функций и модулей
- true и false - булевые значения
- ok - типичный результат успешный результат выполнения
?FOO - хоть официально и называются константами, но по сути - макросы, перед компиляцией заменяются на заранее определенный кусок кода
{foo, bar} - кортеж, набор данных фиксированной длины
[foo, bar] - простой однонаправленный список произвольной длины
"foo" - текстовая строка, представленная в виде однонаправленного списка (что не эффективно с точки зрения потребления памяти, до 4 байт на символ)
<<"foo">> - бинарная строка, может содержать что угодно, в.т.ч. и текст; все что не цифры по возможности лучше хранить в этом типе данных.

Сопоставление (pattern matching)

Очень мощная концепция сопоставления используется в Erlang на каждом углу. В базовом варианте работает примерно так:

{ok, Result} = foo().

Если в функции foo все прошло нормально, то она возвращает, например {ok, 123}, и переменной Result окажется лишь значение 123.

Если же возникла какая-то проблема, то она вернет что-то другое, скажем {error, timeout}, приложение столкнется с несоответствием левой и правой части (атомы ok и error разные) и прекращает свое выполнение (если бы было чего выполнять).

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

Списки

Со списками есть три особые операции:

[Head | Tail ] = [1, 2, 3, 4] - вытащить элемент с головы списка, работает по принципу сопоставления, в Head окажется 1, а в Tail - [2, 3, 4]
[1, 2] ++ [3, 4] - конкатенация, результатом будет [1, 2, 3, 4]
[N * N || N <- [1, 2, 3], N > 1] - выглядит замороченно, по сути это обычный отображение (map) с фильтрацией (filter) - то есть выражение перед || применяется к каждому элементу списка, значение которых попадает в переменную N, а после запятой - условие, накладываемое на N; таким образом результат будет [4, 9]

Бинарные строки

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

Binary = <<Integer:64>> - преобразовать целое число Integer в бинарную строку Binary длиной 64 бита (для примера, может быть любой
<<Integer1:32, Integer2:32>> = Binary - распокавать обратно бинарную строку в целые числа, но уже два по 32 бита; чем-то похоже на операцию [H | T] у списков, но намного более гибко
Binary3 = <<Binary1/binary, Binary2/binary>> - конкатенация бинарных строк, результат окажется в Binary3
<< <<(N * N)/integer>> || <<N>> <= <<1, 2, 3>>, N > 1 >> - аналог последнего примера для списков, только для бинарных данных; результат аналогичен - <<4, 9>>; к слову официально это называется binary comprehensions, а для списков - list comprehensions

Заключение

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

Удачного освоения Erlang!

ООП или не ООП

Иван Блинков — Thu, 23 Sep 2010 13:07:00 +0400

Вчера мне на почту пришло письмо от коллеги с просьбой прокомментировать статью, видимо его же перевода или авторства, о судьбе объектно-ориентированного программирования в современном мире: Почему объектно-ориентированное программирование провалилось?. Собственно говоря, пишу ответ в своем блоге скорее чтобы несколько растопить образовавшийся здесь лед, да и возможно снова затянет - продолжу дальше активно писать в Insight IT.

Для начала хочу вкратце пересказать саму статью. Написана она по мотивам мнений различных экспертов в области разработки, в частности Objects Have Failed by Richard P. Gabriel, November 6, 2002 и holywar'а на конференции OOPSLA с участием именитых специалистов. Аргументы у обоих сторон "за и против" были довольно странноватыми и по сути были подтверждениями и опровержениями различных мифов об ООП, например о том, что с использованием парадигмы ООП разработка идет быстрее/проще/понятнее/удобнее, что ОО языки программирования не соответствуют требованиям вычислительных процессов будущего и не адекватно отражают предметную область, что повторное использование кода есть в любом языке программирование - как минимум в виде библиотек. Сторонники ООП же в основном настаивают на справедливости мифов и твердо отстаивают три основных столпа их парадигмы. На вышеупомянутой конференции по мнению аудитории вверх взяла сторона "против ООП" из-за натиска сторонников языка Lisp и растерянности сторонников ООП касательно своей же теории.

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

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

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

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

Плюс не стоит забывать и о том, какие люди участвуют в разработке: бывают разработчики, которые фанатеют от ООП, всю жизнь занимаются "сборкой" проектов из библиотек на Java или C#, являются ярыми поклонниками TDD и Agile-разработки, а бывают разработчики, которые предпочитают Assembler/C/Fortran/Cobol/Lisp/Haskell/Erlang (нужное подчеркнуть), любят реализовывать очень сложные алгоритмы, оптимизировать их, добиваясь выиграша в несколько миллисекунд во времени или пару килобайт в использованной оперативной памяти. Естественно это лишь крайние или почти крайние случаи, большинство разработчиков скорее всего находятся где-то посередине (к сожалению, у меня нет такой статистики), предпочитая универсальные языки программирования, на которых можно писать код как объектно-ориентированно, так и нет (C++/Python/PHP/etc). Хочется порекомендовать руководителям не заставлять имеющихся в наличии людей заниматься тем, что им не по душе, просто так как Вам кто-то вчера рассказал, что "Ruby on Rails - это круто" или так как во-о-он тот известный проект реализован с использованием во-он тех технологий, языков программирования или парадигм разработки. Используемые технологии и подходы к написанию кода, должны соответствовать поставленным задачам, а команда должна быть готова реализовать проект именно так, как это необходимо, при этом очень большое значение имеет распределение ролей между разработчиками - чтобы каждый занимался своим любимым делом.

Коллеги, копайте ямы лопатами и забивайте гвозди молотками, а не наоборот :)

memcached на пальцах

Владислав Клименко — Wed, 15 Jul 2009 15:09:00 +0400

Ранее уже была сделана публикация с обзором memcached. Давайте вернемся к данной теме и рассмотрим практику работы с memcached на примерах.

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

С уважением,
Иван Блинков

Итак, пара слов о предмете разговора. memcached - это распределенная система кэширования объектов в оперативной памяти. Разрабатывается фирмой Danga Interactive (кстати, они являются авторами не только memcached, но и других интересных проектов). Но о них, возможно, в следующий раз. Обычно memcached используется приложениями для временного хранения данных, которые надо часто читать. Приложения не взаимодействуют (обычно) напрямую с сервером memcached, а работают при помощи клиентских библиотек. На настоящее время созданы библиотеки для многих языков программирования (а для некоторых еще и по нескольку альтернативных) - полный список клиентских библиотек доступен на wiki проекта. В целом, данная схема похожа на работу с БД, знакомую многим разработчикам.

Будем рассматривать установку и использование memcached для Linux. Так же при рассмотрении примеров на PHP и обзоре кэширования сессий потребуются PHP и Apache. Возможно, их придется установить, но мы не будем заострять внимание на вопросах установки.

Сервер memcached

Давайте приступим к установке memcached. Практически во всех дистрибутивах Linux memcached можно установить из репозитариев. Если есть желание собрать самую свежую версию, то можно заглянуть на сайт разработчика (на момент написания этих строк последняя версия - 1.4.0). Также, возможно, понадобится установить libevent. Последняя стабильная версия - 1.4.11

Собираем, устанавливаем и запускаем memcached в режиме вывода сообщений. Интересно же посмотреть, что с ним происходит:

memcached -vv

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

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

Клиенты memcached

Из всего многообразия клиентских библиотек рассмотрим две:

libmemcached (для Си);
PECL extension для PHP (построенный на базе предыдущей библиотеки).

Си

Библиотека libmemcached на данный момент активно развивается и представляется наиболее подходящим выбором при работе с Си и PHP. Также, в комплекте с самой клиентской библиотекой поставляются дополнительные утилиты для работы с memcached, позволяющие просматривать, устанавливать, удалять значения в кэше memcached. Кстати, удивляет, что набор утилит идет не с серверной частью, а с клиентской библиотекой.

Итак, приступим к установке libmemcached. На момент написания этих строк текущая версия libmemcached - 0.31. Компилируем, устанавливаем. Для начала, наслаждаемся чтением страниц man:

man libmemcached
man libmemcached_examples

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

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

memstat - выдает информацию о сервере memcached
memcat - выдает значение по ключу
memrm - удаляет значение по ключу
memdump - выдает список ключей

Для начала посмотрим, что скажет сервер memcached, запущенный нами немного ранее в режиме выдачи сообщений. Запросим статистику сервера при помощи утилиты memstat:

memstat --servers localhost

 Listing 1 Server
 Server: localhost (11211)
 pid: 14534
  uptime: 1950
 time: 1247390264
 version: 1.4.0
 pointer_size: 32
 rusage_user: 0.0
 rusage_system: 0.0
 curr_items: 0
 total_items: 0
 bytes: 0
 curr_connections: 10
 total_connections: 11
 connection_structures: 11
 cmd_get: 0
 cmd_set: 0
 get_hits: 0
 get_misses: 0
 evictions: 0
 bytes_read: 0
 bytes_written: 0
 limit_maxbytes: 67108864
 threads: 5

Получили статистику - следовательно memcached функционирует и откликается на запросы.

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

memcached предоставляет следующий набор основных функций (их, конечно, больше, но здесь приведены основные):

set - занести в кэш пару ключ-значение
add - занести в кэш значение при условии, что значения с таким ключом в кэше еще нет
replace - обновляет кэш при условии, что значение с таким ключом в кэше уже есть
get - получает значение из кэша по указанному ключу

Пример программы на C

Файл mc.c:

#include "stdio.h"
#include "string.h"
#include "memcached.h"

int main( void )
{
    char *key = "key";
    char *value = "value";
    uint32_t flags = 0;
    size_t length = 0;
    char *value2 = NULL;
    memcached_return rc;

    // 1. создать структуру для работы с кэшем
    memcached_st *memc = memcached_create(NULL);

    // 2. указать сервер с которым будем работать
    memcached_server_add(memc,"localhost",11211);

    // 3. занести пару ключ-значение в кэш
    rc = memcached_set(memc, key, strlen(key), value, strlen(value)+1, (time_t)0, flags);

    if (rc == MEMCACHED_SUCCESS) {
    } else {
        // обработать ошибку
    }

    // 4. получить значение
    value2 = memcached_get (memc, key, strlen(key),     & length, & flags, & rc);
    if (rc == MEMCACHED_SUCCESS) {
        printf("%s\n", value2);
        free(value2);
    } else {
        // обработать ошибку
    }

    // 5. высвободить структуру
    memcached_free(memc);
    return 0;
}

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

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

gcc -Wall -o mc mc.c -I/usr/local/include/libmemcached/ -lmemcached

Запускаем:

./mc
 value

Видим требуемое значение - должно быть, заработало!

Для уточнения деталей, смотрим сообщения на сервере memcached:

<32 new auto-negotiating client connection
32: Client using the ascii protocol
32 STORED
32 sending key key
>32 END
<32 quit
<32 connection closed.

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

Посмотрим статистику на сервере:

memstat --servers localhost
 Listing 1 Server
 Server: localhost (11211)
 pid: 14534
 uptime: 4659
 time: 1247392973
 version: 1.4.0
 pointer_size: 32
 rusage_user: 0.0
 rusage_system: 0.0
 curr_items: 1
 total_items: 1
 bytes: 58
 curr_connections: 10
 total_connections: 13
 connection_structures: 11
 cmd_get: 1
 cmd_set: 1
 get_hits: 1
 get_misses: 0
 evictions: 0
 bytes_read: 58
 bytes_written: 58
 limit_maxbytes: 67108864
 threads: 5

Следующие две строчки показывают, что в кэше появилось значение:

curr_items: 1
total_items: 1

Посмотрим на данное значение:

memcat --servers localhost key
 value

Итак, приложение, использующее memcached - готово.

PHP

Для начала установим PECL extension для PHP - memcached

pecl install memcached

На этом этапе возможно появление сообщения об ошибке вида:

ERROR: 'phpize' failed

Это означает, что не установлен пакет php-dev или его аналог. Устанавливаем его и можно пробовать снова:

pecl install memcached
 install ok: channel://pecl.php.net/memcached-1.0.0
 You should add "extension=memcached.so" to php.ini

Как нам и советуют, дописываем extension=memcached.so в php.ini и перезапускаем Apache.

Смотрим информацию об используемом PHP:

memcached support  enabled
Version  1.0.0
libmemcached version    0.31
Session support    yes
igbinary support   no

Пример программы на PHP

Можно смело использовать обращения к memcached из PHP. Как обычно, рассмотрим пример:

<?php
$m = new Memcached();

$m->addServer('localhost', 11211);
$m->set('phpkey', 'phpvalue');
var_dump( $m->get('phpkey'));
?>

Результат работы данного скрипта:

string(8)  "phpvalue"

Итак, PHP-приложение, использующее memcached - готово.

Кэширование данных сессий

Memcached можно использовать и как хранилище данных сессий для PHP. Такой подход часто используется в реальных приложениях. Давайте рассмотрим, что для этого надо сделать.

Вносим изменения в php.ini

;session.save_handler = files
session.save_handler = memcached

;session.save_path = /var/lib/php5
session.save_path = localhost:11211

Параметр session.save_handler указывает, что теперь данные будут храниться в memcached. Второй параметр - session.save_path указывает сервер memcached (их может быть указано несколько, через запятую) на котором будут сохранятся данные.

Перезапускаем Apache - и готово!

Теперь надо проверить, что теперь данные сессии реально хранятся не на диске, а в memcached.

Рассмотрим работу несложного скрипта, заносящего что-нибудь в сессию:

<?php
session_start();
$_SESSION['intval'] = 123;
$_SESSION['strval'] = "qwe";
?>

Запускаем скрипт, он заносит данные в сессию, после чего смотрим на кэш

memdump --servers localhost
 key
 keyphp
 memc.sess.key.3ff8ccab14424082ff83a6dfbcf0941f

Итак - к нашим знакомым по предыдущим примерам ключам, добавился ключ с характерным именем memc.sess.key.3ff8ccab14424082ff83a6dfbcf0941f.

Хранение данных сессии перенесено в систему кэширования. Более подробную информацию по работе с memcached из PHP можно почитать на сайте PHP.

Заключение

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

Интерфейс

Иван Блинков — Sun, 04 May 2008 13:41:00 +0400

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

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

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

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

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

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

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

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

Ключевое слово interface обозначает описание интерфейса;
За ним следует название конкретного интерфейса, которое впоследствии можно будет использовать в коде при его упоминании (некоторые программисты на правах традиции начинают названия интерфейсов с заглавной буквы I, мне в свое время даже пытались объяснить зачем так надо делать, но аргументы не показались мне достаточно весомыми);
Далее идет тело интерфейса, в котором перечисляются все заголовки методов, которые должны быть в классе, реализующем данный интерфейс (никакой реализации!);
Впоследствии приписав к заголовку любого класса ключевое слово implements с последующим указанием названия интерфейса, можно обязать этот класс реализовать указанные в описания интерфейса методы. Существует небольшое исключение для абстрактных классов (то есть классов,для которых не может быть создан объект, обозначаются ключевым словом abstract), они могут и не реализовать все методы интерфейса, но тогда эта обязанность будет переложена на их наследников.

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

Небольшое примечание: сами интерфейсы и методы в их теле по-умолчанию обладают свойствами abstract и public, так что повторно указывать эти ключевые слова не нужно.

На практике же это выглядит это примерно следующим образом:

// описание интерфейса
interface Renderable
{
    // обязуем реализовать метод draw
    public void draw();
}

// конкретная реализация интерфейса
class SomeText implements Renderable
{
   string text;
   public SomeText(string str)
   {
      this.text=str;
   }
   public void draw()
   {
       // вынуждены подчиниться и реализовать
       System.out.println(this.text);
   }
}

// класс-клиент
class Render
{
  public Render(Renderable obj)
  {
     // можно быть уверенным, что
     // метод draw реализован
     obj.draw();
     /*
         в качестве альтернативы можно было бы написать как-то так:
         if(obj instanceof Renderable)obj.draw();
         то есть проверить реализован ли интерфейс
         вместо использования его названия в роли типа данных
     */
  }

В данном примере ситуация тривиальна: класс-клиент Render умеет лишь визуализировать классы, которые он получает в конструктор, вызывая у них метод draw. Для обеспечения такой возможности описан интерфейс Renderable, который реализуется в классе SomeText. Хоть класс Render ничего и не знает о том, какой именно класс ему подсунут, благодаря интерфейсу он сможет вывести на экран любой объект, корректно реализующий наш интерфейс, в том числе и SomeText.

Как я уже упоминал: альтернативой такому подходу является использование полиморфизма и наследования. Такой подход более распространен в других языках программирования, например C++, но пример я приведу все равно на Java, основываясь на предыдущем примере, чтобы читателям было проще сравнивать.

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

// теперь используем абстрактный класс
abstract class Renderable
{
    // реализуем метод draw
    public void draw()
    {
       System.out.println("Вывод на экран недоступен!");
    }
}

// реализация интерфейса (на этот раз неформального)
class SomeText extends Renderable
{
   // на этот раз используем extends (наследование)
   // вместо implements
   string text;
   public SomeText(string str)
   {
      this.text=str;
   }
   public void draw()
   {
       // переопределяем метод draw
       // но могли этого и не делать, тогда
       // использовался бы метод из Renderable
       System.out.println(this.text);
   }
}

// класс-клиент
class Render
{
  public Render(Renderable obj)
  {
     // можно быть уверенным, что
     // метод draw реализован
     obj.draw();
     /*
        на этот раз так как в крайнем случае
        в крайнем случае вызовется хотябы
        метод из класса Renderable
     */
  }

Минимальные изменения - суть та же. Сразу хочу отметить, что этот процесс так прост только в Java, в других языках программирования понадобилось бы использование дополнительных модификаторов для метода draw (например в C#: virtual или abstract в классе-потомке и override в классе-наследнике, это необходимо для обеспечения возможности их переопределения).

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

Design patterns

Иван Блинков — Thu, 24 Apr 2008 13:03:00 +0400

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

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

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

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

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

Основной вклад в этот процесс сделала знаменитая команда, известная как Gang of Four. Она состоит из четырех авторов не менее известной книги "Design Patterns — Elements of Reusable Object-Oriented Software":

Erich Gamma
Richard Helm
Ralph Jonson
John Vlissides

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

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

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

Модификация алгоритма хэширования

Иван Блинков — Fri, 15 Feb 2008 13:17:00 +0300

Если Вы уже успели прочитать одну из моих предыдущих записей о хэшировании, то Вы уже имеете базовое представление о теме сегодняшнего разговора. Одним из возможных способов применения хэшей является хранение аутентификационных данных пользователей интернет-приложения, об особенностях реализации формирования и проверки хэшей при регистрации и авторизации пользователей средствами PHP я и хотел бы с Вами поговорить. Сомневаюсь, что Вы услышите что-то новое, если я скажу, что в PHP даже в "стандартной комплектации" реализована масса алгоритмов хэширования, начиная с широкораспространенных md5(); и sha1(); и заканчивая модулями hash и mhash, в которых реализована еще целая масса алгоритмов. Все они давно уже стандартизованы и доступны для изучения всем желающим получить о них какую-либо информацию.

Допустим мы храним пароли пользователей в виде какого-то стандартного хэша, для примера - md5, в базе данных. Все было отлично, но в один прекрасный момент нашелся подлый злоумышленник, который неким хитрым способом получил доступ к базе данных логинов и паролей. Перед ним стоит цель - узнать изначальный пароль у максимального числа пользователей. Посмотрим на ситуацию с его стороны:

Первым делом он бы попытался определить, какой именно хэш перед ним находится - чаще всего это делается либо просто взглянув на длину хэша, либо если приложение широко распространено (популярная CMS скажем) - покопавшись в ее исходниках, еще есть вариант найти свой собственный аккаунт - и зная пароль попробовать на нем разные алгоритмы, способов можно придумать множество - все ограничивается лишь воображением. Узнав ответ на свой вопрос ему лишь останется набрать в Google фразу вроде "md5 decrypt", а дальше уже дело техники.
Еще один вариант решения задачи - взглянуть на список хэшей на предмет наличия совпадений. С очень высокой степенью вероятности за значительной группой одинаковых хэшей будет скрываться какой-либо банальный пароль вроде 123456.

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

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

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

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

<?php
function generateHash($input,$salt = false)
{
  if(!$salt)$salt=randomString(2);
  $hash=md5($input.$salt);
  return $salt.substr($hash,2);
}
?>

Как не трудно заметить - используется самодельная функция randomString();, которая возвращает случайную строку, состоящую из указанного количества шестнадцатеричных цифр (надеюсь Вы в состоянии написать ее своими силами). Именно этот момент и гарантирует элемент случайности при каждой новой генерации хэша. В том месте, где я прочитал про этот механизм (ссылку, к сожалению, привести не могу - в bookmark'ах не нашел), этот случайный компонент назывался словом salt, смысл его заключается в том, что он приписывается ко входным данным, передаваемым стандартной функции хэширования, а затем им же подменяется какая-либо фиксированная часть полученного хэша. Наверняка у Вас возник вопрос: а как же потом понять, что пользователь ввел верные данные, ведь для тех же исходных данных получится другой хэш и возможности их сравнить не будет? Ответ достаточно прост, его можно было увидеть даже в коде: при повторной инициализации хэша из базы данных достается заранее известная часть хранящегося там хэша, соответствующего конкретному пользователю - тот самый salt, и передается нашей функции. В этом случае в механизме будет использоваться именно он, а не новое случайное значение, и, как следствие, в случае правильности введенных данных на выходе получатся совпадающие хэши. Вот такой вот простенький, но иногда достаточно полезный трюк.

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

На пути к идеалу

Иван Блинков — Thu, 07 Feb 2008 15:39:00 +0300

...или 15 привычек, которые помогут ускорить PHP-приложение

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

Прочитав достаточно солидный объем разного рода документации по PHP, я часто натыкался на статьи и тексты, так или иначе связанные с производительностью PHP-скриптов. Порой в такого рода источниках информации удавалось найти достаточно интересные и неочевидные факты об этом языке программирования, которые не смотря на свою простоту могли дать вполне заметный прирост к производительности итогового приложения. Я почему-то очень серьезно стал относиться к производительности написанных мной скриптов, и довольно часто стал испытывать на практике спорные моменты в реализации, о которых узнавал из Сети или каких-либо других источников, с помощью самописных или opensource benchmark'ов, хотя порой и просто внедряя в реальные приложения. Как ни странно, в большинстве случаев практика подтверждала теорию, и я стал постоянно пользоваться этими простыми правилами, о которых я и хочу Вам рассказать.

Повышения значения индекса с помощью ++\$i;

Этот факт был наверное одним из самых удивительных для меня, когда я впервые о нем услышал, но действительно операция ++\$i; выполняется несколько быстрее, чем \$i++;. или другие вариации на ту же тему вроде \$i+=1;. Привычка использовать в качестве индекса цикла переменную под названием i, казалось бы стара как Мир, мне она досталась в наследство от C, а в месте с ней "в комплекте" шла привычка писать выражение i++ в заголовках циклов. Разница в скорости обработки этих выражений, насколько мне известно, обусловлена разным количеством элементарных машинных операций, которые необходимо выполнить процессору (в точных цифрах не уверен, пишу по памяти, но ++\$i; требует трех элементарных операций, а \$i++; – четырех). В справедливости этого факта не трудно убедиться, достаточно написать простенький скрипт, состоящий из цикла с достаточно большим количеством итераций, и замерить любым способом точное время его выполнения при использовании разных способов инкрементации индекса цикла.

Вывод статического контента без помощи PHP

Сейчас тот факт, что использование интерпретатора PHP для вывода статического контента сильно замедляет этот процесс, кажется мне очевидным, но поначалу я использовал echo там, где он был необходим, ничуть не чаще, чем там, где он лишь замедляет работу скрипта. От использования еще менее эффективного способа - print, меня избавила моя лень: писать каждый раз на одну букву больше дико не хотелось (в отличии от echo, print возвращает информацию об успешности выполнения своей работы, что в большинстве случаев просто-напросто не нужно). Проверить опять же не трудно - нужен лишь объемистый текстовый файл, который достаточно вывести в browser разными способами и засечь уходящее на это время.

Вывод статического контента из отдельного файла

Частенько при желании выполнить указанное в заголовке действие по привычке используют include, require или их _once версии, что является далеко не самой лучшей идеей с точки зрения производительности. Самым быстрыми быстрыми и экономичными поотношению к оперативной памяти являются функции readfile и fpassthru. В качестве доказательства этого факта приведу таблицу, демонстрирующую статистику выполнения этой операции различными методами и позаимствованную с одного англоязычного сайта:

Функция	Время (сек.)		Оперативная память (байт)
Функция	32Kb файл	1Mb файл	32Kb файл	1Mb файл
file\_get\_contents	0.00152	0.00564	52480	1067856
fpassthru	0.00117	0.00184	20016	20032
fgets	0.00195	0.07190	30760	30768
file	0.00157	0.06464	87344	2185624
require\_once	0.00225	0.08065	67992	2067696
readfile	0.00117	0.00191	19192	19208

Вывод переменных

Наверняка вам известно, что переменные можно выводить с помощью конструкции вроде echo "\$var text";, что является одним из самых удобных вариантов решения этой задачи благодаря минимальному количеству символов, которые необходимо набрать, но с точки зрения быстродействия этот вариант далек от идеала, так как влечет за собой достаточно серьезные преобразования в памяти сервера, эффект которых порой бывает заметен невооруженным глазом. Частично ущерб производительности можно сгладить заменой этой конструкции на echo \$var." text";, что приводит к несколькому усложнению внешнего вида кода и несколько поправляет ситуацию со скоростью выполнения. Но как известно знак . обозначает конкатенацию двух строк, что тоже требует некоторых вычислений и затрат памяти, но и от нее можно избавиться, заменив на запятую. Выражение echo \$var," text"; ничем по своему эффекту не отличается от предложенных ранее вариантов, за исключением максимального быстрого выполнения, обусловленного отсутствием дополнительных преобразований в процессе передачи просто последовательности из константы и переменной.

Избегайте выполнения лишних действий

Достаточно абстрактное утверждение, но тем не мение постоянное напоминание себе о нем может избавить Вас от совершения массы ошибок. Самой широкораспространенной является наверное вызов какой-либо функции (чаще всего count(); или strlen();) в проверке условия выхода из цикла. Когда-нибудь доводилось писать видеть в собственном или чужом коде выражение вида for(\$i = 0; \$i \< count(\$array); ++\$i) { ... }? А задумываться о последовательности выполнения действий при его обработке? Стоит только немного начать размышлять и ошибка становится очевидной: count(); выполняется при каждой итерации цикла, что приводит к подсчету количества элементов массива при каждой проверки условия выхода из цикла - почему бы не посчитать это значение заранее и сравнивать значения индекса с переменной, а не с результатом выполнения функции?

@

Использование этого оператора стоит избегать при каждой возможности. Казалось бы такое простое действие, как сокрытие вывода возможного сообщения об ошибке, влечет за собой достаточно трудоемкую последовательность действий: устанавливает значение параметра PHP-интерпретатора error_reporting = 0, выполняет указанное за этим оператором действие, возвращает значение error_reporting в исходное состояние.

Маленькие мелочи

Развивая тему предыдущего подраздела, хочется обратить внимания, что даже на еще более элементарных вещах можно сэкономить драгоценное процессорное время:

Вместо условия if(\$variableOne == \$variableTwo) { ... } можно написать if(\$variableOne === \$variableTwo) { ... }, что избавит от проверки на соответствие типов данных и приведения их друг к другу, в некоторых случаях эти действия эти случаях эти действия конечно же и бывают необходимы, но бывает это далеко не часто.
Глядя на выражения вроде if(\$boolean == true) { ... }, я чаще всего вспоминаю цитату из одного малоизвестного интернет-ресурса: if (b.ToString().length \< 5) { ... }. Хоть и не имет никакого отношения к PHP, но суть проблемы отражает очень ярко.
Самым очевидным способом проверить попадает ли длина строки в какой-либо диапазон является использование функции strlen(); и сравнение полученного результата с фиксированными значениями, но зачем выполнять лишний вызов функции, если можно воспользоваться услугами конструкцией языка PHP isset(); для определения наличия в строке определенных символов. if(isset(\$str{5})) { ... } приведет к абсолютно тем же результатам, что и if(strlen(\$str)>4){ ... }
Битовые операции выполняются намного быстрее относительно обычных арифметических действий. Об этом факте редко вспоминают, да и работать с ними умеет далеко не каждый, но порой они бывают очень актуальны, особенно при частой работе с числами кратными двойке.
Угадайте, что делает интерпретатор при виде надписи 1/2? Правильно: делит 1 на 2. Зачем лишний раз утруждать его, когда можно написать просто половину - 0.5.
При возвращении значения переменной из функции при помощи global выполняется на порядок больше действий, чем при классическом return.
Конечно же фраза \$array[text]; интерпритируется практически точно так же, как и \$array['text'];, но зачем выполнять лишнее преобразование из необъявленной константы в строку, проверять, что такой константы все же не существует, выводить сообщение типа E_NOTICE, если можно всего этого не делать?
По возможности не используйте require_once(); или include_once(); неоднократно по отношению к одному и тому же файлу. При отсутствии какого-либо эффекта, попусту тратится время на обработку повторного запроса.
Даже "безобидных" ошибок стоит избегать, лишняя проаерка потратит не так много процессорного времени, как генерирование достаточно длинного сообщения об ошибке и вывод его в stdout, stderr или лог-файл, а также не стоит забывать, что даже "безобидные" ошибки могут стать потенциальной угрозой безопасности приложения вцелом.

В заключении...

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

Unix way

Иван Блинков — Sun, 06 Jan 2008 19:30:00 +0300

На эту тему в Сети можно найти несметное количество статей и обсуждений, не удивлюсь если Вам уже доводилось читать что-либо подобное в прошлом или может быть работать в одной из множества операционных систем, разработанных с использованием этой идеологии. За этим словосочетанием скрывается целая философия разработки программного обеспечения, начавшая свое развитие в середине 90-х годов прошлого века и воплощенная в огромном количестве операционных систем и в еще большем количестве opensource проектов. В этом тексте я хочу поведать Вам свой взгляд на эту философию с двух точек зрения: программиста и пользователя.

Наиболее точно охарактеризовать то, о чем пойдет речь можно лишь процитировав одного из основателей традиций Unix и разработчика технологии под названием "Unix pipes" - Douglas'а Mcllroy'а:

"This is the Unix philosophy: - Write programs that do one thing and do it well. - Write programs to work together. - Write programs to handle text streams, because that is a universal interface."

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

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

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

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

Взгляд с точки зрения программиста

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

Как же это выглядит?

Одна задача - одна программа

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

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

Unix pipes

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

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

Взгляд с точки зрения пользователя

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

У каждой элементарной программы, соответствующей этой идеологии, должен быть входной и выходной стандартные текстовые потоки - stdin и stdout соответственно. Механизм unix pipes позволяет перенаправлять эти потоки любой программы произвольным образом с помощью трех простых операторов: |, > и <. Первый из них - | перенаправляет stdout команды слева от него в stdin команды справа, а > и < предназначены для перенаправление потоков в/из файлы по схожему принципу.

Предлагаю рассмотреть этот механизм на примерах. Возьмем несколько базовых утилит, имеющихся на практически любой unix-like системе:

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

Начнем с примера, позволяющего прочитать постранично любой файл:

cat readme.txt | less

Не смотря на наличие более простых методов достижения той же цели, этот пример наглядно демонстрирует процесс перенаправления ввода-вывода, другими словами с помощью оператора | была создана так называемая pipe, которая и дала название этому механизму. Пример, демонстрирующий перенаправление в файл будет столь же элементарным, хотя может быть с первого взгляда покажется "пострашнее":

cat readme.txt | grep unix > readme.txt

Этот пример должен был бы удалить из файла все строки, где нет слова "unix". Маленькое замечание: при использовании такого перенаправления, перед началом передачи данных файл обнуляется. В этом и заключается ошибка данного примера: файл очищается до того, как поток данных успел пройти через фильтрацию grep, что приводит к просто очистке файла. Если же Вам все же нужен отфильтрованный список строк - стоит разместить в другом файле (которым можно было бы подменить исходный при необходимости), просто поменяв его название:

cat readme.txt | grep unix > meread.txt

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

cat readme.txt | grep unix >> readme.txt

В unix-like системах есть еще одна интересная особенность, косвенно связанная с этим механизмом: все устройства являются файлами и соответственно, прикреплены к файловой системе, для них выделена отдельная директория, по традиции называемая /dev. Работа с ними также ведется на тех же правах что и с обычными файлами, например набрав в консоли:

cat readme.txt > /dev/dsp

в ответ от компьютера Вы услышите некоторый звук, издаваемый из колонок или наушников.

Подводим итоги

С точки зрения простого пользователя использование opensource решений, построенных на базе философии unix, является как минимум нетривиальной задачей - ведь от него требуется как минимум понимание насколько мощная и гибкая система попала ему/ей в руки. Отсутствие единственного верного способа решения той или иной задачи ставит большинство людей попросту в тупик, у них начинают разбегаться глаза от десятков тысяч программ, доступа к которым есть у всех пользователей unix-like операционных систем, с помощью набора простой волшебной команды в консоли, состоящей не более чем из трех-четырех слов.

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

Три основных компонента парадигмы объектно-ориентированного программирования

Иван Блинков — Sat, 05 Jan 2008 22:28:00 +0300

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

Вы спросите у меня: как это все может быть связано с темой этой записи? - об этом я и собираюсь Вам поведать.

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

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

наследование
инкапсуляция
полиморфизм

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

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

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

class Human
{
  public int height; // рост
  public int age; // возраст
  public String gender; // пол
  public String eyesColor; // цвет глаз
  public String hairColor; // цвет волос
}

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

class Human
{
  public int height; // рост
  public int age; // возраст
  public String gender; // пол
  public String eyesColor; // цвет глаз
  public String hairColor; // цвет волос
  public void walk()
  {
    System.out.println("Я иду!");
  }
  public void work()
  {
    System.out.println("Я работаю в большом офисном здании");
  }
}

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

Наследование

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

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

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

class Director
{
  public int height; // рост
  public int age; // возраст
  public String gender; // пол
  public String eyesColor; // цвет глаз
  public String hairColor; // цвет глаз
  public void walk()
  {
    System.out.println("Я иду!");
  }
  public void work()
  {
    System.out.println("Я работаю в большом офисном здании");
  }
  public void idle()
  {
    System.out.println("Я ничего не делаю!");
  }
}

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

class Director extends Human
{
  public void idle()
  {
    System.out.println("Я ничего не делаю!");
  }
}

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

Полиморфизм

Это слово пришло к нам из греческого языка, понимания этого термина легко достичь, просто переведя его на русский язык: πολύμορφος - многоформенность. То есть в наиболее простом случае подразумевается использование одной и той же переменной (или массива) для хранения информации об объектах, описываемых разными классами. Представим, что нам необходим стандартизованный способ узнать кем же работает тот или иной человек, естественно для этого необходимо описание соответствующего метода для выполнения этой функции в каждом классе, причем он должен одинаково называться в каждом из них. Для реализации этого примера на языке Java нет необходимости использовать дополнительных ключевых слов (в отличие от, например, C#, где необходимо использование слова virtual в заголовке метода в базовом классе и override - в производных). Продолжая приводить примеры на Java имеем три производных класса (для упрощения опустим дополнительные методы, которые могли бы присутствовать):

class Director extends Human
{
  public void work()
  {
    System.out.println("Я работаю директором!");
  }
}

class Programmer extends Human
{
  public void work()
  {
    System.out.println("Я работаю программистом!");
  }
}

class Manager extends Human
{
  public void work()
  {
    System.out.println("Я работаю менеджером!");
  }
}

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

class AskHuman
{
  public static void main(String[] args)
  {
    public Human person;
    person = new Director();
    person.work();
    person = new Manager();
    person.work();
    person = new Programmer();
    person.work();
}

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

Я работаю директором! Я работаю менеджером! Я работаю программистом!

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

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

interface Worker
{
  public void work();
}

class Director extends Human implements Worker
{
  public void work()
  {
    System.out.println("Я работаю директором!");
  }
}

class Programmer extends Human implements Worker
{
  public void work()
  {
    System.out.println("Я работаю программистом!");
  }
}

class Manager extends Human implements Worker
{
  public void work()
  {
    System.out.println("Я работаю менеджером!");
  }
}

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

Инкапсуляция

Наверняка Вы уже задавались вопросом о том, что же значит слово public во всех предыдущих примерах. Это ключевое слово является частью реализации механизма инкапсуляции в языке Java, суть его состоит в том, чтобы дать возможность определить область видимости для составных частей класса, это очень актуально при написании ПО, использующего библиотеки, plug-in'ы или при написании программы группой людей. Ведь если Ваш класс подразумевает какие-либо ограничения для переменных или методов (например - возраст не может быть отрицательным), то их легко обойти воспользовавшись прямым доступом к ним из-за пределов класса или просто выполнив наследование.

Для предотвращения этого используется система параметров, назначаемых переменным и методам внутри класса для присвоения им "уровней доступа" (на примере опять же Java, но в большинстве известных мне высокоуровневых языков используется та же система):

public - назначается по-умолчанию - полностью свободный доступ
private - доступ предоставляется только другим компонентам класса
protected - доступ предоставляется остальным компонентам класса, а также всем наследникам данного класса

Данный механизм является незаменимым помощником разработчиков любых более-менее крупных проектов, следующих принципам ООП.

Вместо заключения

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

Объектно-ориентированное программирование: а что же это?

Иван Блинков — Fri, 04 Jan 2008 21:39:00 +0300

Находишься в поисках способов облегчить свой труд в процессе написания программного обеспечения? - об одном из них мы сегодня и поговорим.

Сама концепция этого подхода к программированию достаточно проста для понимания, и заключается она в...

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

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

Для начала напомню тот факт, что в языках высокого уровня простейшими элементами, доступными программисту, являются:

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

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

Класс

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

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

Объект

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

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

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

Пара простых способов повысить эффективность написания кода

Иван Блинков — Thu, 03 Jan 2008 20:52:00 +0300

Начнем, пожалуй, издалека: если рассматривать процесс программирования чуть более глобально, чем просто как дальний синоним слова coding, то нетрудно прийти к выводу, что реализация хоть сколько-нибудь большого проекта невозможна просто с помощью следования банальному алгоритму: сесть за компьютер, бросить взгляд на ТЗ, открыть любимый текстовый редактор, взять в зубы клавиатуру и написать. Если говорить о проектах уровня "Hello, world!" такой алгоритм вполне пригоден для реального использования, но как только речь заходит о чем-либо более серьезном и полномасштабным, такой подход сразу начинает порождать несметное количество проблем.

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

Временным спасением от подобного рода проблем может послужить привычка грамотно оформлять код:

Размещение строго по одному выражению на строке в комбинации с поддающимся хоть какой-либо логике расставления отступов в начале строки позволяет избежать потерянных выражений и четко понимать: а где же заканчивает вон то-о-от цикл?
Осмысленные названия переменных резко сокращают время, необходимое для осознавания ответа на вопрос "а что же она значила?" Мне доводилось не раз сталкивался с кодом, написанным с использованием в качестве абсолютно всех переменных разнообразных букв латинского алфавита - мало того что изменить их на что-либо другое как автозаменой, так и RegExp'ами проблематично, так и на разобраться что к чему ушло очень продолжительный период времени. Существует большое количество более адекватных способов названия переменных и функций, перечислять их все смысла не вижу, по-этому кратенько расскажу о том, которым предпочитаю пользоваться сам: алгоритм прост как три копейки - название соответствует переведенному на английский смыслу (переменную, содержащую чье-либо имя называем name), в случае если слов требуется более одного слова - пишем их слитно, начиная все кроме первого с заглавной буквы (например: veryLongName), и по старинной традиции делаем исключение для индексов циклов, которые называем буквами латинского алфавита начиная с i и далее по списку. Вот собственно говоря банальный способ, позволяющий в очень сжатые сроки вспомнить как называлась переменная, содержащее имя :)
Подавляющее большинство языков программирования поддерживает разбавление кода комментариями, что существенно упрощает ориентирование в объемистых листингах как самим автором, так и всеми остальными персонами, которым по тем или иным причинам доведется в последствии читать произведение. Особенно этот способ актуален для низкоуровневых языков программирования, так как с первого взгляда на код даже его автору порой проблематично определить его значение.

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