23 Августа

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

Посему несколько мыслей в её развитие и в реакцию на прозвучавшее в форуме.

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

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

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

Но даже решив её, мы не оказываемся у цели. Ведь опять-таки, транзакция - значит откат на точку её завершения. Откат - значит локальное движение назад по времени. Локальное - значит, откатом мы привносим рассогласование между откатываемой сущностью и остальным миром.

Пример. Мы открываем соединение по TCP/IP, начинаем качать и тут - трах-бабах, питание упало и поднялось. Мы, как честные девочки, восстанавливаем всё с контрольной точки и выясняется, что мы уже нашли себе неприятность. Если контрольная точка была до того, как открыто соединение, мы попытаемся открыть его снова, в то время как сервер ещё будет пытаться возродить старое. В некоторых протоколах это приведёт к облому открытия нового - например в POP3. Если контрольная точка была зафиксирована уже после установления соединения, но мы потратили много времени на рестарт, удалённая система может решить, что мы померли совсем и разорвать связь со своей стороны. Тогда после пробуждения мы окажемся лбом у стены - мы считаем, что сокет открыт, а там считают, что мы зря так считаем.

Нельзя сказать, что всё это нерешаемо, но проблема, очевидно, есть.

Теперь если мы обладаем ЭН ОЗУ. Во-первых, не нужны транзакции и постоянная фиксация состояния системы на диске - это экономит нагрузку на диск и повышает быстродействие. Во-вторых скорость перезагрузки существенно больше - не нужно разбираться, где мы там упали. Только встать и пойти дальше. И, наконец, отсутствует как класс обратное течение времени - мы продолжаем ровно с того места, где споткнулись.

Разрыв времени всё равно есть, так что часть проблем останется и потребует решения. Но - лишь часть, да и с учётом ускорения рестарта даже она окажется решаемой меньшей кровью. В сумме же при использовании ЭН ОЗУ реализация устойчивых систем упрощается категорически.

Так что MAGRAM - штука безусловно революционная. Только бы ей не помереть на пути к рынку.

Об устойчивости и fault toleranc-е. Это - два взгляда на почти что одну и ту же проблему. FT танцует от надёжности системы - это одна цель. Устойчивость танцует от концепций и идеологий, и в этом смысле нужна даже там, где надёжность вообще несущественна - то есть просто никаким боком.

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

Нам, товарищи, это чуждо. :-) Какую задачу решает ОО? Для чего именно нужно структурное программирование? В конце концов, пол подметать за каким хреном? Только чтоб тараканов не было? Упорядоченность подхода самоценна, ибо из неё запросто растут мириады новых путей, неочевидные, пока не вползёшь в горку нового метода. А втащишь себя на неё, матерясь на неудобства - гля, а там сколько всего нового и полезно-прикладного открылось.

Применительно к устойчивости. Я считаю, что объектно-ориентированное программирование - беcполезный термин. Его не бывает, этого ООП. Как не бывает езды по горам или поедания капусты, кидания лески в воду или таскания пластиковой коробочкой по пластиковой подложке. Все эти процессы не имеют самостоятельного названия, так как не самоценны. Мы не ездим по горам ради процесса, мы едем в гости к деду, а горы - ну, на пути подвернулись. Мы ловим рыбу и для этого кидаемся леской в реку. И все эти процессы мы никак не называем - выделенное название для них не имело бы смысла! Ведь суть определяется не тем фактом, что мы швырнули в воду именно леску, а тем, что на конце её крючок, на нём - наживка, место - рыбное, а мы умеем подсекать. Вот сколько всего нужно, чтобы поймать рыбу. А леска - так, частность. Существенная, конечно, но деталь.

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

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

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

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

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

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

Нетрудно догадаться, к чему я это. На роль другого кирпичика просится устойчивость, persistence. С появлением оной устойчивости исчезают некоторые болезни, казалось бы, ООП присущие. Другие компоненты более тривиальны. Например, исключения (exceptions), причём не просто использование их, а ещё и запрет на неиспользование, то есть на все иные методы сообщения о не успешности выполнения той или иной части кода. Конечно, как и с goto, этот запрет вряд ли безусловен и кто-то найдёт уникальную ситуацию, в которой удобнее обойтись без exception, но это должно быть редкостью.

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

Но есть уверенность, что ООП - не коктейль, и пить его в чистом виде могут только алкоголики. :-)