Модели, объекты, поведение, интерфейсы

[Dimka]

Прочитав одну холиварную статейку с критикой ООП:

http://www.melikyan.com/dalshe/articles/oop2.html

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

Код: (Text)

aParent appendAsChild: aChild.
aChild setAsParent: aParent.

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

Потому хотелось бы этот вопрос обсудить. А для затравки предлагаю построить общую модель для описания ситуаций:

Ваня ударил по мячу.
Мяч перелетел через забор.
Мяч разбил окно.
Таня уронила мяч в реку.
Мяч не утонул в реке.

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

[zubr]

Тип взаимодействия = (утонул, не утонул, разбил, перелетел);
Тип действия = (ударил, уронил);
Объект человек
{
Свойства:
Возраст, рост, вес...
Методы:
  virtual Тип взаимодействия Действие(Тип действия, объект удара, объект взаимодействия)
  {
       if((объект удара == Мяч) and (объект взаимодействия == Река))
      return не утонул;
      else if(...............
  }
}

Объект Мяч
{
     Свойства:
     Материал, вес, диаметр...
   
}

Объект Река
{
     Свойства:
    Ширина, глубина, скорость течения...
}

Объект Окно
{
      Свойства:
      Ширина, высота, количество рам...
}

[Finch]

Ну для начала, у меня небольшой вопрос. Что, так Lisp крут, что бувально в 20 строках умешается и анализатор и исполнитель кода? Или автор это сказал, так, для красного словца.

Насчет Вани, объект мяч не знает, кому он принадлежит. Но Ваня произвел над ним действие. Которое привело к воздействию на объект стекло, которое принадлежит другому объекту типа челвек. Назовем его для краткости Георгий (можно просто Гоша (с)). Данное воздействие на стекло, привело Гошу в состояние полного дизбаланса настроения. Что привело в выбросу довольно большой дозы адреналина в его организме. Он не стал выяснять у мяча Вани, принадлежность к объекту. Он просто проследил, откуда данный объект прибыл. Вышел и "вежливо" попросил Ваню сопроводить его (Гошу) к родителям Вани. Так Ваня знает, свою принадлежность к родительским объектам. Ну дальше Гоша описал животрепешиюю ситувцию с его окном. И попросил Родителей Вани о небольшой компенсации его материального и морального ушерба. После ухода Гоши, естественно родители Вани произвели над ним некоторые меры воспитательного характера.

Вот по этому расказу наверно можно построить интерфейс объектов. И заодно воспроизвести креш тест

[Dimka]

ОО программа записывается как предложения естественного языка (только более формально). Каждое предложение состоит из подлежащего (субъекта действия - некоторого объекта в программе), сказуемого (действия - некоторого метода того объекта в программе, который является субъектом), дополнений, определений и обстоятельств (параметров метода). Особенно чётко этот принцип прослеживается в Smalltalk. Можно записать:

Код: (Text)

Vanya kicks: theBall.
theBall breaks: theWindow.

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

Код: (C++)

vanya.kicks(theBall);
theBall.breaks(theWindow);

Конечно же компилятор заменит такой код на:

Код: (C)

kicks(vanya, theBall);
breaks(theBall, theWindow);

Разница состоит в том, что методы объекта характерны именно для этого объекта (или всех объектов класса - в зависимости от языка). А функция не является характерной для конкретного объекта (или объектов класса - в зависимости от языка).

Мне кажется, что предложенное zubr является попыткой в первом приближении построить интерпретатор естественного языка. И, соответственно, эта идея в нынешних условиях в полной мере нереализуема - всегда найдутся ограничения; а границ применимости предложенного решения, тем не менее, не обозначено. Скажем так, предложенное решение является работоспособным решением для перечисленных предложений, но оно не ориентировано на развитие модели и в этом смысле не является продуктивным: оно не даёт ответа на вопрос о том, является ли такое решение наилучшим в данной ситуации. Чем такой метауровень:

Код: (Text)

aMan do: action with: object.

лучше, чем конкретная запись:

Код: (Text)

Vanya kicks: theBall.

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

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

Что такое "утонуть в реке"? Ведь это не действие тонущего объекта - не он сам это делает, а так происходит с ним (хотя в естественном языке это так не выражается). И это не действие реки (не она топит), а так происходит с ней. По сути это взаимодействие двух объектов, следствие сочетания их свойств, но в чём оно выражается? Можно ли его описать на уровне интерфейсов объекта, реки и, возможно, чего-то третьего, являющегося средой или ареной взаимодействия, не вводя вспомогательных понятий дна, поверхности, глубины, плотности воды и тонущего объекта?

[Dimka]

Любая программная система должна перерабатывать входную информацию в выходную или сохранять.

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

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

[Sla]

Вполне попадает под ООП

Объект - действие - результат

из логики выпадает выражение

Мяч не утонул в реке.
но это уже относится к свойствам объекта.

[Dimka]

но это уже относится к свойствам объекта.

Ключевой вопрос: какого именно?

[Sla]

А где тонет мяч?

[Dimka]

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

[Вад]

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

[Dimka]

Вад, нет, это возможный способ построения моделей.

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

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

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

[Sla]

Допустим.
Появилось две сущности, которые не поддаются логике ООП

Мяч перелетел через забор.
Мяч не утонул в реке.

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

[zubr]

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

[Dimka]

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

Ну и про эффективность работы всего получающегося сооружения тоже обычно говорить не приходится.

[zubr]

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

[Dimka]

zubr, ничего не меняет по сути, если модули разрабатываются автономно друг от друга.

Про "всё взять и переписать" - это понятно. Только дорого.

С точки зрения проблемы фактически нет разницы между:
- приложением в рамках комплекса,
- модулем в рамках приложения,
- объектом в рамках модели.

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

[zubr]

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

Логично по принципу модуль-задача или модуль-подзадача. Задача естественно подразумевает не просто условие, но и конечную цель.

[Dimka]

Логично по принципу модуль-задача или модуль-подзадача. Задача естественно подразумевает не просто условие, но и конечную цель.

Это если задачи не имеют пересечений в предметной области.

Смотрел м/ф "Мы делили апельсин"? У каждого (включая волка) была задача его съесть. Только у остальных ещё была задача не ссориться друг с другом, а у волка такой задачи не было. Причём цели у всех были противоположные. И так получилось в этой истории, что выбор способа решения частной задачи был обусловлен дополнительной информацией о других решаемых задачах.

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

[Dimka]

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

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

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

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

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

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

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

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

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


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

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

[Sla]

dimka, ощущение такое, что это цитаты из монографии к кандидатской или докторской

[RXL]

Подумалось, что не плохо бы сделать на сайта коллекцию, где будут ссылки или текст таких постов.

dimka, а может статью?

[Dimka]

Sla, а что делать, если мысли мучают

[Dimka]

Для любителей ботаники и теорий систем проблема: росянка.

Росянка - хищное (насекомоядное) покрытосеменное (цветковое) растение (травянистое). Вопрос, как оно появилось эволюционным путём?

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

В конце эволюции появилось отнюдь не мирное растение, живущее как правило на бедных почвах (болота, пески), и потому питающееся насекомыми. Со свойствами:
- корни получают из почвы в основном воду и недостаточное количество минеральных веществ;
- листья модифицированные, плотные, у некоторых видов даже почти не зелёные (функции фотосинтеза выполняют слабо), выделяющие клейкую слизь и желудочный сок, содержат чувствительные палочки-рецепторы, при раздражении которых насекомым, происходит быстрое сворачивание листа и формирование "внешнего желудка", где жертва переваривается, минеральные вещества, белки, жиры и углеводы всасываются;
- цикл охоты: 1) лист развёрнут, покрыт клейкой слизью, рецепторы расправлены, 2) если попадает посторонний предмет, лист перестаёт выделять клей, высыхает, и предмет сбрасывается ветром, 3) если попадает насекомое, палочки облепляют жертву, лист тут же начинает сворачиваться, 4) свёрнутый лист представляет собой закрытую камеру, стенки начинают выделять желудочный сок, расщепляющий жертву, 5) расщеплённые простые вещества всасываются поверхностью листа, 6) когда остаётся лишь неперевариваемый хитиновый покров, лист раскрывается и далее на шаг 2, рассматривая остатки как посторонний предмет;
- нервная система отсутствует;
- обмен веществ: вода поступат снизу вверх, остальное - сверху вниз.

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

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

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

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

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

Что, собственно, и предлагается. Какие будут идеи?

[Finch]

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

[Dimka]

Хорошо. Итак первая функция.

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

Аналогично ведёт себя кислица (заячья капуста), но медленнее, чем мимоза.

Механизм тут такой.

Исходное состояние - свёрнутое.

Для разворачивания растению нужно потратить энергию, которую оно накапливает за счёт дыхания.

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

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

Через некоторое время блокирующий фермент распадается, и растение вновь готово развернуться, если процесс фотосинтеза не прекратился.

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

[Dimka]

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


Вторая функция.

Ещё одним распространённым явлением среди растений является покрытие волосками стеблей и листьев. Волоски препятствуют движению насекомых-вредителей.

Можно предположить, что предок росянки обладал также и волосками.


Третья функция.

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

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

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

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

Можно предположить, что предок росянки вёл себя подобно дикому картофелю.


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

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

Решив её, мы получим сочетание свойств, отдельно полезных растению, но в совокупности дающих законченую подсистему охоты.

Остаётся ещё расписать подсистему переваривания и подсистему распознавания жертв.

[Dimka]

Неожиданно нашёл историческое подтвеждение своим идеям.

http://www.happy-pm.com/blog/?p=2327

Путь камикадзе Сергея Королева

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

А через пару недель одна из наших замечательных соседок сорганизовала экскурсию к этим самым тарелкам, которые на поверку оказались Евпаторийским Центром Космической Связи. Там в свое время готовился к полету Юрий Гагарин, трудился Сергей Павлович Королев и все такое. Классная была экскурсия, прекрасный музей, в котором даже лежат перфокарты, на которых что-то там обсчитывалось.

Тарелки же оказались реально огромными. Площадь - порядка площади футбольного поля. Собственно, при помощи этих тарелок получили знаменитое “Поехали!”, а также менее известное “Товарищи, я горю”, когда корабль Гагарина входил в плотные слои атмосферы.

Я как обычно начал прикидывать, насколько масштабным был проект по созданию такой вот тарелки. История же меня поразила до крайности. Срок проекта был один год. Я когда это услышал, даже присел. Коллеги, вдумайтесь, один год! На то, чтобы все спроектировать, выстроить производство, произвести, собрать, протестировать…

Собственно, с самого начала было ясно, что проект самоубийственный. Выстроить производство за такой короткий срок нереально. Однако Сергей Павлович Королев не читал книги товарища Йордона “Путь камикадзе “(наверное, по той причине, что Эд Йордон тогда еще заканчивал школу ). Поэтому он взял помощников, подумал и двинул на кладбище кораблей в одной из бухт Севастополя. В результате чего, частями конструкции антенны стали:

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

2. Корпус итальянской подводной лодки 1931 года выпуска.

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

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

Заодно плавно склоняюсь к мысли, что самые сильные решения возникают именно на пути камикадзе. В ситуации: "Сделай или умри." Или (в биологической интепретации): "Изменись или умри."

[zubr]

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

[Dimka]

имхо, далеко не самый лучший

Для меня висящее в воздухе слово "лучший" - это пустой звук. Укажи конкретные достоинства и недостатки в сравнении с другими подходами.

[zubr]

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