AVC wrote:
>> > Качественная архитектура должна быть расширяемой. Это означает, что
>> > разработчик должен спрогнозировать возможные направления развития
>> > системы.
> C>Сразу все возможные направления? Не подскажете, случайно, как это сделать?
> *В принципе* (на деталях не настаиваю) — как в Обероне.
Ррррррррррр.

> В основе минимальный набор основных модулей.
Если честно, то мне плевать на модули. Совсем.

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

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

> Система расширяется добавлением новых модулей поверх предыдущих.
Ничерта не "расширяется". Просто "добавляется".

Здравствуйте, Cyberax, Вы писали:

>> *В принципе* (на деталях не настаиваю) — как в Обероне.
C>Ррррррррррр.


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

>> В основе минимальный набор основных модулей.
C>Если честно, то мне плевать на модули. Совсем.
C>У меня почти все программы "монолитны", то есть сделаны в виде одного
C>большого изображения. Но тем не менее расширяемы на уровне исходного кода.
C>И вот как организовать архитектуру, чтобы ее можно было расширять — это
C>мне гораздо интереснее сомнительной возможности загружать модули в рантайме.

OK.
Интересы бывают разные.
Меня, напротив, привлекает легкость и безболезненность компонентного программирования.

>> Система расширяется добавлением новых модулей поверх предыдущих.
C>Ничерта не "расширяется". Просто "добавляется".

Хм... в чем разница?
Разве расширяемость не то же самое, что:
1) возможность добавления новой функциональности
2) без внесения изменений в другие модули (или иные программные единицы — для других языков)?

Здравствуйте, AVC, Вы писали:

AVC>Разве расширяемость не то же самое, что:
AVC>1) возможность добавления новой функциональности
AVC>2) без внесения изменений в другие модули (или иные программные единицы — для других языков)?

BTW, это вполне можно понимать в ТРИЗовском смысле — как удовлетворение противоречащим друг другу требованиям.

Здравствуйте, Кирилл Лебедев,

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

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Здравствуйте, Геннадий Васильев,

КЛ>Вы опять читаете невнимательно, из сказанного берете только половину, а половину – упускаете. Над взятой половиной надстраиваете уже свои интерпретации и с ними спорите.

ГВ>> Общепринятый смысл термина "идеальность", это, всё-таки, приближение к некоей идее, в нашем случае — идее решения некоторой задачи.

КЛ>Процитирую еще раз определение идеальности, выделив пропущенные Вами места:

КЛ>Идеальная система – это система, которой нет, а функция ее выполняется.

КЛ>В данном случае функция как раз и есть та идея, к которой, в своем развитии, стремится система. И реализация этой функции (идеи, если Вам близок платонизм) тем ближе к идеалу, чем меньше ресурсов потрачено на ее (идеи) реализацию.

Любопытное высказывание. Любопытно оно своей слишком заметной двусмысленностью. С одной стороны — да, чем меньше затрат на разработку, тем лучше. С другой, разработка состоит по большому счёту из двух стадий — первичной разработки и длительного цикла сопровождения. Затраты на первичную разработку (реализацию) программы — это, "в среднем по больнице" где-то около 10%-40% от затрат на весь её жизненный цикл. То есть, с точки зрения стоимости девелопмента ключевой момент — стоимость сопровождения. А стоимость сопровождения, в немалой степени — функция понятности исходного текста. Понятность — суть характеристика взаимодействия человеческого разума с объектом. То есть, "понятность" невозможно рассматривать в отрыве от сопровождающего программиста.

Что получается? А получается, что неправомерно сводя обобщённую характеристикаму "идеальности" к конкретным свойствам программы можно попасть впросак. Например, можно закопаться в первичной стадии, пытаясь предусмотреть всё на свете, а можно и неоправданно усложнить сопровождение. Никогда не слышали о том, как ругаются програмисты в адрес менеджеров, которые говорят: "Это написано и работает — значит не надо ничего менять". Да, оно работет, но им неудобно пользоваться!

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

ГВ>>Вы противоречите сами себе. Если уж система развивается, а "идеальность" тем выше, чем система меньше, то становится ясно, что система развивается всегда только в одном направлении — к не-идеальности.

КЛ>Это не я противоречу сам себе, а Вы уподобляетесь схоласту, который, имея пару посылок, строит силлогизм и пытается, таким образом, вывести (дедуктивно) законы всего сущего. Или, наоборот, построить чисто формальное опровержение, основываясь на все тех же силлогизмах.

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

КЛ>Но схоластика потерпела фиаско на рубеже 16 – 17 веков. С наиболее аргументированной критикой такого подхода выступил Фрэнсис Бэкон в своей работе «Новый Органон».

КЛ>Оставаясь в рамках формальной логики, Вы вряд ли сможете постигнуть законы развития технических систем, как, собственно говоря, и любые другие законы, например, Закон Всемирного Тяготения или Второй Закон Ньютона, т.к. эти законы формально (при помощи силлогизмов) не выводятся.

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

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

Это более чем известно. Называется "уровнями абстракции". Не всегда разумно исключать воплощение уровня абстракции — это тоже далеко не новость.

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

Внимание! С какой точки зрения? Только с точки зрения энергозатрат на перемещение! А по такой характеристике как цена/качество это может быть совсем не так.

---

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

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

И в этом смысле идеальная программа вступает в противоречие с "идеальностью" в трактовке ТРИЗ. Даже более того! "Идеальная" ТРИЗ-овская программа подвергнется немедленной "де-идеализации" — проявлению, переработке, развитию, обкладыванию трассировками, логгированием и т.д., и т.п.

Например, с точки зрения ТРИЗ нет ничего предосудительного в том, чтобы воспользоваться каким-то побочным эффектом, скажем, функции быстрой сортировки. Например, количеством обращений к элементам сортируемого набора. Однако, это приведёт к появлению иной раз нежелательной зависимости клиентской части от внутренностей самой функции. Потом мы поменяем quick_sort на, например, bubble_sort и получим какой-то непонятный эффект. Чтобы избежать этого программисты напишут новую функцию, например count_array_by_specific_algorithm, т.е. — деидеализируют имевшееся решение. В чём прагматизм? В том, что в последнем случае в текст программы будет добавлен явно выраженный элемент, отражающий некоторое требование к системе.

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

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

Здравствуйте, Кирилл Лебедев, Вы писали:

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

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

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>1. Умение использовать для постановки и решения задач различные модели, разумеется, благо. И паттерны – хорошая модель, потому что она проста. Эта модель доступна даже студенту. Или, скажем так, она гораздо доступнее, чем системное мышление или идеальность. Это – как приемы в ТРИЗ, которые всем доступны и всем понятны. Поэтому большинство людей и пользуются ими.

Поверьте на слово. С вами спорят далеко самые не типичные представители "большинства".

КЛ>2. Казалось бы, раз приемы (паттерны) доступнее и понятнее, то нужно выявить как можно больше приемов, и, благодаря этому, получить возможность решать все новые и новые классы задач. Однако практика показалась тупиковость такого подхода. Скажем так, существует ограничения на качественный уровень задач, которые можно решить при помощи приемов. Поэтому в ТРИЗ и появились другие инструменты: стандарты, физические противоречия, физэффекты и т.п. Соответственно, и в нашем случае основная цель – это не переоткрыть паттерны, а создать инструментарий более высокого класса, который бы позволял решать более сложные и менее очевидные задачи.

Внимание! Ключевое слово — "физические"!

КЛ>3. Разумеется, более сложный инструментарий предъявляет и более высокие требования к квалификации того, кто им будет пользоваться. Конечно, проблему с датчиками можно устранить паттерном “Visitor” или двойной диспетчеризацией. Но лучше вообще так не проектировать. В ряде случаев паттерны выступают в роли «заплатки», которая закрывает архитектурные «глюки».

В точку.

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

Угу, ППКС! Только теперь давайте подумаем не об абстрактных "думать" и "напрягаться", а об их конкретных воплощениях.

КЛ>Качественная архитектура должна быть расширяемой. Это означает, что разработчик должен спрогнозировать возможные направления развития системы. Для этого он должен не смотреть на систему в одиночестве (саму по себе), а желательно посмотреть на систему в контексте. Т.е. должен видеть и систему, и надсистему, и отдельные подсистемы. Желательно, еще и в развитии. Здесь мы вплотную подступаем к системному мышлению. А это – не такая уж простая штука, и простым набором паттернов здесь не обойдешься.

И это правильно. Скажу больше — паттерны нередко только замусоривают мышление.

КЛ>4. Все выше изложенное свидетельствует о том, что дискуссия вызвана не только и не столько разницей инструментария (паттерны, ТРИЗ), но и разницей в квалификациях.

Вот смотрите. Сейчас вы отталкиваете от себя тех, кто уверен в своей квалификации, поскольку апеллируете к тому, что часть ваших оппонентов — неквалифицированные специалисты. А что, если поставить вопрос о критериях определения квалификации? Знаете, сколько тут копий поломано?! Потому-то люди и пришли, в частности, к двум очень простым вещам:

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

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

КЛ>Можно, например, до посинения спорить, что трубка курительная и «трубка» телефонная суть разные вещи, и не понимать, что данное различие обусловлено избранным критерием – функцией системы или технологическими «наворотами». Те же самые предметы, но в иной системе отсчета, могут быть однородными, т.к. функциональные или технологические различия в ней не важны. В качестве примера такой системы я уже приводил опись имущества, принадлежащего конкретному человеку.

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

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

Кстати, как раз в программировании в случае необходимости оперирования "объектами собственности" сделают не объекты ТТрубка и ТТелефон, а ограничатся каким-нибудь ТОбъектСобственности. И рассуждать будут уже только о харатеристиках объектов собственности!

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

---

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

Фразу:

ГВ>С вами спорят далеко самые не типичные представители "большинства".

Читать как: С вами спорят далеко не самые типичные представители "большинства".

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Внимание! Ключевое слово — "физические"!

Вряд ли.
AFAIR, в ТРИЗ "физические" противоречия отличаются от "административных" тем, что в них противоречивые требования предъявляются к одному объекту.
Думаю, что "природа" объекта здесь не так важна.

ГВ>Вот теперь догадайтесь, какое из этих правил вы сами и нарушаете.

Геннадий, мне просто интересно: а вот такое высказывание

http://www.rsdn.ru/Forum/Message.aspx?mid=1785096&only=1

ничего не нарушает?

Здравствуйте, AVC, Вы писали:

ГВ>>Внимание! Ключевое слово — "физические"!

AVC>Вряд ли.
AVC>AFAIR, в ТРИЗ "физические" противоречия отличаются от "административных" тем, что в них противоречивые требования предъявляются к одному объекту.
AVC>Думаю, что "природа" объекта здесь не так важна.

"Физический" объект это не совсем то же самое, что и "информационный" объект. Не нужно сводить методологию к метафизике.

ГВ>>Вот теперь догадайтесь, какое из этих правил вы сами и нарушаете.

AVC>Геннадий, мне просто интересно: а вот такое высказывание
AVC>http://www.rsdn.ru/Forum/Message.aspx?mid=1785096&only=1
AVC>ничего не нарушает?

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

ГВ>...сие высказывание не не нарушает.
Имеется ввиду: "...сие высказывание не нарушает".

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Внимание! Ключевое слово — "физические"!

AVC>>Вряд ли.
AVC>>AFAIR, в ТРИЗ "физические" противоречия отличаются от "административных" тем, что в них противоречивые требования предъявляются к одному объекту.
AVC>>Думаю, что "природа" объекта здесь не так важна.

ГВ>"Физический" объект это не совсем то же самое, что и "информационный" объект. Не нужно сводить методологию к метафизике.

"Физический" объект, действительно, не совсем то же самое, что и "информационный".
Но ведь "физик", как и программист, мыслит все же головой, а не руками, например.
В методах мышления вполне может быть много общего.
"Техническое" противоречие фиксирует отношение между двумя элементами системы (один "улучшаем" — второй "ухудшается").
Это, так сказать, на поверхности.
А "физическое" противоречие докапывается — почему не получается исправить первый, не портя второй.
Суть в том, что где-то мы предъявляем противоположные требования к одному элементу системы.
Терминология, конечно, несет суровый отпечаток первоначальной сферы применения ТРИЗ.
Что есть — то есть.
Но, в принципе, речь идет о системном мышлении. А оно не ограничено одной сферой применения.

ГВ>Ох, грешен, грешен. Только вот ни одно из упомянутых мной правил сие высказывание не не нарушает. Я же там не теорию излагаю, а банально ругаюсь.

А-а... Это меняет дело.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Возвращаясь к трубкам и телефонам, по критерию владельца они действительно однородны, но при этом становятся не "трубкой" и "телефоном", а "объектами собственности".

Заметьте, становятся только после того, как выбран соответствующий критерий. А это говорит нам о том, что термины подсистемны к контексту (выбранному критерию), который для них является надсистемой.

ГВ>Кстати, как раз в программировании в случае необходимости оперирования "объектами собственности" сделают не объекты ТТрубка и ТТелефон, а ограничатся каким-нибудь ТОбъектСобственности. И рассуждать будут уже только о харатеристиках объектов собственности!

Разумеется, так и произойдет. Но для начала курительные трубки и "трубки" телефонные нужно поместить в надлежащий контекст.

Здравствуйте, AVC, Вы писали:

ГВ>>"Физический" объект это не совсем то же самое, что и "информационный" объект. Не нужно сводить методологию к метафизике.

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

+1

AVC>"Техническое" противоречие фиксирует отношение между двумя элементами системы (один "улучшаем" — второй "ухудшается").
AVC>Это, так сказать, на поверхности.
AVC>А "физическое" противоречие докапывается — почему не получается исправить первый, не портя второй.
AVC>Суть в том, что где-то мы предъявляем противоположные требования к одному элементу системы.

+1

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

AVC>Терминология, конечно, несет суровый отпечаток первоначальной сферы применения ТРИЗ.

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

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

AVC>Что есть — то есть.
AVC>Но, в принципе, речь идет о системном мышлении. А оно не ограничено одной сферой применения.

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

Здравствуйте, Кирилл Лебедев, Вы писали:

ГВ>>Возвращаясь к трубкам и телефонам, по критерию владельца они действительно однородны, но при этом становятся не "трубкой" и "телефоном", а "объектами собственности".

КЛ>Заметьте, становятся только после того, как выбран соответствующий критерий. А это говорит нам о том, что термины подсистемны к контексту (выбранному критерию), который для них является надсистемой.

Вопрос, как всегда, в словах. Не более того.

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

Вот смотрите, система "накладная", кроме прочего, состоит из упоминаний об определённых предметах, а не из самих предметов. То есть, предметы не принадлежат накладной, а только упоминаются в ней. Принадлежат накладной довольно-таки абстрактные сущности, называемые "позициями накладной". Я исхожу из того, что "принадлежность" означает, как минимум, некоторое влияние владельца на владеемое. Так, например, если уничтожить накладную, то вместе с ней исчезнут и "позиции", но сами предметы от того никуда не пропадут. Точно также, я, как владелец, могу, например, набить трубку табаком и закурить. А вот что может сделать с трубкой накладная — непонятно. Потому и неуместно употребление термина "принадлежит" иначе как для иллюстративных нужд. И тем более неверно делать какие-то выводы на базе некорректно сформулированной посылки ("предмет принадлежит накладной"). Как программист, я с такой казуистикой знаете сколько нахлебался?!

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

Я подобрал нестрогое выражение для "превращения" трубок в позиции документа. Трубки только упоминаются в документе. Сами по себе они частью документа не становятся.

ГВ>>Кстати, как раз в программировании в случае необходимости оперирования "объектами собственности" сделают не объекты ТТрубка и ТТелефон, а ограничатся каким-нибудь ТОбъектСобственности. И рассуждать будут уже только о харатеристиках объектов собственности!

КЛ>Разумеется, так и произойдет. Но для начала курительные трубки и "трубки" телефонные нужно поместить в надлежащий контекст.

Возвращаемся к вопросу, на который я так ещё и не получил ответа. Что такое "контекст"?

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

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

А что имеете ввиду вы?

Здравствуйте, Cyberax, Вы писали:

>> Хе-хе. Вот нет в Java оператора "super super" для доступа к методу не
>> родителя, а дедушки и попробуй это нарушить. А вопрос, как это сделать,
>> я видел и в ru.java и на rsdn.
C>Просто решили не делать, так как нечасто требуется. Никаких
C>фундаментальных запретов для super.super нет.

Если это философский вопрос, то понятно, что любую "фундаментальность" можно оспорить А если взять конкретно JVM, то ограничение вполне фундаментально.

>> the need of some of Morph’s clients to use the protocol provided in
>> Collection to enumerate the submorphs.
C>Вопрос такой: а зачем нужно реализовывать протокол коллекций?

Под протоколом коллекций имеются ввиду внутренние итераторы. Собственно там дальше приводятся 3 альтернативы. Персонально я, при прочих равных, сейчас бы делал "fat interface". Две другие — возвращать просто копию коллекции, и некую обёртку (например, ReadStream, который есть внешний итератор).

>> Ы?
C>Обычная ситуация — противоречие показывает, что у нас неправильная
C>архитектура (требуется доступ к приватным данным) или на недостаточность
C>архитектуры.

Ну, блин, это банальность.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>С вами спорят далеко самые не типичные представители "большинства".

ГВ>Читать как: С вами спорят далеко не самые типичные представители "большинства".

Занятно. Так и прочитал. Что написано по другому — обратил внимание только сейчас.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>А с чего вы взяли, что идеальный код — это код, которого нет

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

Здравствуйте, Кирилл Лебедев, Вы писали:


КЛ>Тем не менее, другие инструменты и понятия ТРИЗ (высокого системного уровня), например, законы развития технических систем, идеальность, системный оператор могут быть использованы для решения сложных "программистских" задач. Собственно, мы это попытались показать в своих статьях. Например, статья "Освобождение узников оператора "IF" (http://www.triz-ri.ru/themes/method/creative/creative57.asp) как раз про системный оператор.

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

КЛ>К сожалению, сложные инструменты ТРИЗ (законы, идеальность, системный оператор) предъявляют высокие требования к квалификации человека, который их применяет. Опыт показал, что большинство людей, использующих ТРИЗ, применяют приемы. Кропотливый разбор задачи по АРИЗ или постановка задачи при помощи системного оператора дается, увы, не многим. Аналогичная ситуация складывается и в программировании — большинству людей удобнее применять паттерны (аналог приемов) и рефакторинг, чем качественно и кропотливо ставить задачу, рассматривать вещь не саму по себе, а в контексте, в группе. Честно Вам скажу, разнесение сущностей по разным системным уровням (выделение подсистемы, системы и надсистемы) — еще та задачка. (Здесь я, конечно же, не имею в виду совсем тривиальные вещи типа колеса, автомобиля и автотранспорта, где системные уровни всех трех сущностей очевидны.)

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

КЛ>Тем не менее, более простые инструменты ТРИЗ, "заточенные" под решение "программистских" задач создать все-таки возможно. Только для этого нужно пользоваться не простым переносом приемов из "железной" ТРИЗ, а созданием и анализом информационного фонда. Собственно, такая работа уже ведется, и опубликованные статьи — лишь "первые ласточки".

Извините пока такой работы не видно. Видна только чистая философия, на ней далеко не уедешь.

Здравствуйте, AVC, Вы писали:


AVC>Я хочу сказать, что применение вполне "тризовских" методов может иметь место и без лейбла "ТРИЗ".

Если любую диалектику обозвать тризом то можно