Ответ на »сообщение 4430« (Андрей)
___________________________
Господа, когда же вы, наконец, подерётесь?
счегоэтофдрук?

Господа, когда же вы, наконец, подерётесь?

Ответ на »сообщение 4422« (Владимир Лось)
___________________________


Я не понимаю - в чём проблема?
Либо у вас чётко оговоренные постулированные интерфейсы. Либо - о какой компонентности мы с вами говорим?

Проблемы нет. Я просто пытаюсь ее найти :) Модули бывают с исходниками и без исходников. "Базар" начался с модулей Черного ящика, которые хотелось править. С модулей в исходниках.

Надо всяческим образом елозить менеджеров мордой об асфальт при первом же их вяканьи на счёт "надо быстрее показать что-нибудь работающее!". Это самое "что-нибудь" так "что-нибудью" и останется до самой кончины проекта. Или, при его выживании – вашим вечным хомутом и гирей... :о(

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

Ответ на »сообщение 4425« (Сергей Перовский)
___________________________
>>>В чем же плюсы?
>>>В отсеве разработчиков, не способных мыслить на уровне создания расширяемых модульных систем. Или вообще - проектировать системы... :о(
Не выйдет :(
Правильно!
Потому, что, по аналогии с классиком: "А учителя – кто?"
Я уже писал про препода по программированию в одном из харьковских вузов, который (на чистом глазу и в методичках по лабам!) рекомендовал на стадии анализа наследовать класс "заказ" от классов "посетитель_ресторана" и "блюдо"... так о чём дальше говорить?!... :о) :о(

Я ж говорю, средства лишь поддержка направления идей. А куда нас такое мЫшленье приводит? Правильно в царство сомнений "а на кой мне эта ваша модульность, когда монолит – удобней!" При такой традиции именно так! Почему-то все понимают, что сравнивать и складывать гусей с яблоками нельзя, а вот работать в ОО-средах и языках "как бог на душу положит" – эт всегда пжалста! :о)

Эти бравые ребята напроектируют компонентные системы так, что реализация займет массу времени и исходный код будет еще длиннее.
Время реализации .
"Ну шо, зуб удалять будем с обезболиванием или бесплатно?" :о)
Вообще-то за последнее время, я всё больше прихожу к выводу, что ОБЩЕЕ время НА ПЕРВОЙ ИТЕРАЦИИ реализации проекта будет БЕЗУСЛОВНО ПРОДОЛЖИТЕЛЬНЕЙ!
Но! Это – НЕ УНИВЕРСАЛЬНОЕ ПРАВИЛО ИЛИ ЗАКОН!
В большинстве случаев МОМЕНТ ВРЕМЕНИ ПОЛУЧЕНИЯ ПЕРВОГО РАБОТАЮЩЕГО ФРАГМЕНТА КОДА будет несколько позже, по сравнению, с "монолитом" ( который "из головы – в клаву" :о) )
Но, вы не забывайте, что следующие итерации и наращивание уровня и количества требований заказчика, модернизация программы, перепроектирование ОБЯЗАТЕЛЬНО будут. И что тогда? - вешаться? Или опять заплатки лепить?
Надо всяческим образом елозить менеджеров мордой об асфальт при первом же их вяканьи на счёт "надо быстрее показать что-нибудь работающее!". Это самое "что-нибудь" так "что-нибудью" и останется до самой кончины проекта. Или, при его выживании – вашим вечным хомутом и гирей... :о(

Средства разработки не могут их отпугнуть.
Ну дык про одного идиота и сто мудрецов помните? Деятельный, энергичный дурак может, по-началу, создать о себе отличнейшее мнение у начальства... и – срулить! При епрвых же признаках "течи"... А остальным "серым лошадкам" всё это потом разгребатьи ПОДДЕРЖИВАТЬ. Вынужденно. Потому, что тот активный придурок уже заложил архитектуру и на этой основе прописан код, который "как-то, но работает"... И тут, на вопросы и возражения новых людей в проекте, менеджеры (в святом гневе!), на предложение новых работников перепроектировать и переписать код, обычно выдают: "но у него-то работало". Их же НЕ ИНТЕРЕСУЮТ ДЕТАЛИ РЕАЛИЗАЦИИ, им надо хвосты пушить перед заказчиком! А то, что даже "незначительные переделки"  и "мелкие поправки" (знакомые слова, правда?) могут просто обрушить весь проект (или значительную часть его подсистем), это, видимо у них просто на извилины не ложится...

Поэтому задача должна стоять по другому: средство разработки должно по возможности заставлять проектировать правильно.
"Пряников" уже имеем – обкушаемся скоро. Теперь бы ещё "кнут" изобресть и куда-нить пристроить... :о)

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

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

Ответ на »сообщение 4426« (Владимир Лось)
___________________________
Торопился - последние юниты на карточке выходили, сделал ошибки... :о)

Не может x++++ трактоваться как (x++) в (x++)++ НЕ ЕСТЬ lvalue!!!
Читай так:
Не может x++ трактоваться в х++++ как (x++).
(х++) в (x++)++ НЕ ЕСТЬ lvalue!!!

Для "простенького пример пусть int а = 5;

Ответ на »сообщение 4424« (Андрей Хохлов)
___________________________
Программист много чего может написать, но есть у меня сомнение, что в Си (а также в Java/C#) x+++++y есть (x++)+(++y). Оно трактуется как ((x++)++)+y.
Вот, блин, всегда меня удивляет "плинтусовый" уровень знаний этих приверженцев-знатоков "самого-самого"!

Не может x++++ трактоваться как (x++) в (x++)++ НЕ ЕСТЬ lvalue!!!

А пробелы здесь при том, что x+++++y можно записать и как x+ ++ ++y, и как x++ + ++y.

Вы хоть компилятор-то пытались запускать, если уж в книжки не глядим?! :о)

--------------

Да что с такими "наворотами"!
Вы вот попытайтесь предсказать, что напечатается в таком простеньком случае:

printf("a=%d a=%d", a++, a++);
printf("a=%d a=%d", a++, ++a);
printf("a=%d a=%d", ++a, a++);
printf("a=%d a=%d", ++a, ++a);

а потом проверьте себя компилятором и задайтесь вопросом, "АПАЧЕМУУМИНЯНИТАК?!"

Ответ на »сообщение 4415« (Владимир Лось)
___________________________
>>>В чем же плюсы?
>>>В отсеве разработчиков, не способных мыслить на уровне создания расширяемых модульных систем. Или вообще - проектировать системы... :о(
Не выйдет :(
Эти бравые ребята напроектируют компонентные системы так, что реализация займет массу времени и исходный код будет еще длиннее.
Средства разработки не могут их отпугнуть.
Поэтому задача должна стоять по другому: средство разработки должно по возможности заставлять проектировать правильно. Поэтому от создателей новых средств разработки я прежде всего жду методики проектирования контрактов, а не методики проектирования на основе контрактов.
Можем мы хотя бы отличить плохую систему интерфейсов от хорошей?
Боюсь, что чисто интуитивно.
А нужны формальные признаки.

Ответ на »сообщение 4423« (Сергей Губанов)
___________________________

Программист много чего может написать, но есть у меня сомнение, что в Си (а также в Java/C#) x+++++y есть (x++)+(++y). Оно трактуется как ((x++)++)+y.

О пробелах я не подумал, но в тексте статьи (в переводе-точно) пробелов нет - <code>x+++++y</code>

Ответ на »сообщение 4417« (Андрей Хохлов)


Как понимать следующее:

На языке C программист может написать конструкцию x+++++y, загадку, а не выражение, представляющую проблему даже для сложного синтаксического анализатора


Буквально понимать. На языке Си программист может написать такое, что даже сложный синтаксический анализатор будет поставлен в тупик. А человека - тем более. Вот Вас например в тупик поставил код "x+++++y", который на самом деле есть "(x++) + (++y)". Вот и синтаксический анализатор тоже такое не поймёт - ему надо будет пробелы расставить или скобки чтобы он понял.

Ответ на »сообщение 4420« (Старик Оберон)
___________________________
Безболезненное и минимальное изменение. Подумаем. Безболезненное для кого/чего? Для автора, новоявленного соавтора ("расширятеля"), модуля, всей системы? Как насчет авторского надзора? Всяк, кто тронет, посягнет на задумку. Берем оловянного солдатика. А теперь начнем безболезненно пластилином лепить к нему наши овеществленные фантазии. Что получится? Значит, могут быть модули подконтрольные автору и неподконтрольные ему.
Не понятны ваши проблемы.
Модуль вы купили(скачали, переписали)? Купили
Вы им получили возможность пользоваться? Получили.
Зачем он вам был нужен? Он обеспечивает некую функциональность.
Почему вы в этом уверены? Постулирован опубликованный интерфейс модуля.
Вы желаете что-то "чуть-чуть подправить"?
Теперь объясните - ЧТО? Что вы сможете "налепить пластелином", кроме того, что позволено автором модуля?
Я не понимаю - в чём проблема?
Либо у вас чётко оговоренные постулированные интерфейсы. Либо - о какой компонентности мы с вами говорим?

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

[QuoteМинимальное изменение - это вроде как для детишек переводные картинки? Раскрасить можно, но просто водой (никаких там красок). А самому что подрисовать - ни-ни. Значит, модули могут быть "макияжные"
(переводные картинки) и трансформируемые (LEGO).
А вот здесь, уж извините, всё (почти всё) решает опыт, умения и грамотность (да и талант, канечно) проектировщика. А, в связи с тем, что как мы все прекрасно знаем у 90% всего этого не имеется в достатке, то нужны "костыли-подпорки" и "линейка для шаловливых ручек" в виде соответствующего набора языковых и инструментальных средств. Оно конечно, приятно себя осознавать "типа бэтмэн", купив костюмчик оного героя, но с небоскрёба прыгать я всё равно не рекомендовал бы. Я это к тому, что каким бы распрекрасным,"мощным и гибким" ни был инструмент или язык, только само обладание ими автоматически качества мышления и подходов к работе не изменит...