> Обсудим идеи как можно радикально облегчить и упростить программирование?

Ждёшь когда её кто-то спроектирует за тебя?
А ты тогда зачем нужен?
Какой-же ты тогда программист?

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

Когда например над кодом делают ревью, рефакторинг и т.п.
Короче причесывают и приводят в Божеский Вид.
Семантика при этом мало меняется. А вот внешний вид может поменяться радикально

Ждёшь когда её кто-то спроектирует за тебя?

Да я не против.

А чтобы семантику отследить, надо инструмент сравнимый по сложности с компилятором

А толку?

Зато существующие CVS-системы хорошо работают с файлами с неизвестной им семантикой.

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

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

Это понятно. Но при этом в программирование вносится достаточно сложный и трудоемкий процесс проектирования архитекуры.

Это понятно. Но при этом в программирование вносится достаточно сложный и трудоемкий процесс проектирования архитекуры.

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

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

В общем случае - это набор методов, для каждого из которого сформулирован чёткий контракт

Я точно с программистом разговариваю?

С учётом того, как вы употребляйте <прим. СОВСЕМ ДРУГИЕ. НЕ ОТНОСЯЩИЕСЯ К ПОЛИМОРФИЗМУ> термины - высока вероятность, что нет, не в курсе.

Т.е. я и про полиморфизм не в курсе?

что - полиморфизм

Что же Вы совершенно незнакомого человека, об опыте и знаниях которого Вы не имеете НИКАКИХ представлений, фактически лузером называете?

А то, что пользователь класса зависит от того, какие типы используются в интерфейсе класса - ну да, факт

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

Оказывается Вы до сих пор ходите на курсы (упоминалась аббревиатура RUP). Сколько можно учиться?

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

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

Докажите. Если Вы не тролль. Дам Вам еще один шанс.

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

в смехогрехе санитарный день?

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

Таким образом, класс X уже "завязался" на 4 класса: Y,Z,W,U.

Мне ни разу не приходилось продумывать одновременно все контракты

А вот кстати - какие бы ты книги посоветовал на эту тему, кроме уже упомянутой?

Ну предъявите же этот худший случай! Я просто не представляю, как можно так влипнуть.

Читать умные книжки про принципы проектирования систем, системный анализ, архитектуру, паттерны проектирования и т. п. Хотя бы осилить букварь Гарди Буча "Объектно-ориентированный анализ и проектирование".

Поймите - вы делаете вброс, из которого видно, что вы совершенно не разбираетесь в предмете.

Вы либо нормальным языком рассказываете, либо я пас общаться с Вами.

А что дальше? А как этого можно избежать/обойти? А что еще можно придумать?

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

А Вам не приходило в голову, что в software можно изменить само понятия "контракта"?
И уйти от представления интерфейса в виде списка кортежей

Ага. Есть у меня такой скилл.

Вы так говорите, как будто рады этому.

Вообще то именно для этого и существует этап проектирования

Вы передергиваете.
Программирование это все же не электрика.
Поэтому и назвали software в противоположность hardware.
И проблемы, существующие в hardware, сглажены или вообще отсутствуют в software. И в software допустимы такие трюки, которые в hardware привели бы к катастрофе или огромным затратам.

Исмаил, вы очень толсто троллите.

Ну да. Куда нам. Конечно же я не в курсе про абстрактные классы и чисто виртуальные методы. Спасибо что открыли Америку.

Но ладно. Представим себе такую ситуевину - серебряную пулю изобрели и интерфейсы (и контракты) стало можно менять незаметно для пользователей. И вот однажды приходит Исмаил к себе домой, а там вся техника - сгоревшая. Это просто электрики (никого не предупредив) изменили контракт интерфейса - вместо 220 начали подавать 380. Не, нуачо? Можно ведь... Или вот яблочники - нет, чтобы пользоваться стандартным Micro-USB, изобретают вот новые яблоки. Был разъём для ушей - и нету теперь. Нужно специальные адаптеры покупать. Не, нуачо? Явочным образом менять контракты и интерфейсы - это ведь так здорово!

Тут можно было бы рассказать про техники уменьшения связности

Т.е. мало того, что программист должен ПРОДУМАТЬ интерфейсы СРАЗУ ВСЕХ зависимых (в т.ч. косвенно) классов, так он при проектировании должен ЗАРАНЕЕ предусмотреть какие изменения возможны в системе интерфейсов.
Т.е. задача еще больше усложняется.

Насчет орграфа зависимостей я знаю, мне непонятно только, ПОЧЕМУ непременно должны получаться хрупкие монстры, малейшие изменения в которых рушат весь код?!