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

S>Что за бред?
S>Компиляция в модули известна полсотни лет. Я лично ей пользовался ещё в начале девяностых, на машинках с 500K b юзер-спейса.

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


V>>То бишь, в нынешней схеме запросто можно иметь зависимости от некомпилябельных проектов — главное, чтобы интерфейсные h-файлы описывали что требуется, а наполнить "тела" можно и в процессе, что позволяет на плюсах достичь намного лучшего разделения труда, чем в C# и Джаве.
S>Это речь уже не о модульности, а об особенностях конкретного ЯП.

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

От особенностей ЯП растут растут уникальные для ЯП доступные практики.
Например, крупные проекты на C# меня раздражают именно озвученным — всё должно быть одновременно компилябельным, чтобы я мог хоть как-то работать с привычной для себя скоростью.

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

Уверен, тебе бы и в голову такого не пришло, т.к. тебе не с чем сравнить.
Но там есть за чем понаблюдать — как именно большинство С# программистов решают задачи.))
Они решают их натурально "пошагово", причём, довольно малюсенькими шажочками: сделают кусочек — проверят, еще небольшой кусочек — опять проверят.

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

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

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

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


V>>В этих технологиях аналогичное традиционно достигается через натурально перебарщивание с интерфейсами.
S>Во-первых, откуда "перебарщивание"? Вам так хочется, чтобы модуль А зависел от конкретного типа, определённого в модуле Б?

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

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

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

На этом я точно пока остановлюсь, остальное после.
Жду работу над ошибками — что не так в твоём вопросе?
(там несложно)

Разберешься — приходи.

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

S>Что за бред?
S>Компиляция в модули известна полсотни лет. Я лично ей пользовался ещё в начале девяностых, на машинках с 500K b юзер-спейса.

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


V>>То бишь, в нынешней схеме запросто можно иметь зависимости от некомпилябельных проектов — главное, чтобы интерфейсные h-файлы описывали что требуется, а наполнить "тела" можно и в процессе, что позволяет на плюсах достичь намного лучшего разделения труда, чем в C# и Джаве.
S>Это речь уже не о модульности, а об особенностях конкретного ЯП.

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

От особенностей ЯП растут растут уникальные для ЯП доступные практики.
Например, крупные проекты на C# меня раздражают именно озвученным — всё должно быть одновременно компилябельным, чтобы я мог хоть как-то работать с привычной для себя скоростью.

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

Уверен, тебе бы и в голову такого не пришло, т.к. тебе не с чем сравнить.
Но там есть за чем понаблюдать — как именно большинство С# программистов решают задачи.))
Они решают их натурально "пошагово", причём, довольно малюсенькими шажочками: сделают кусочек — проверят, еще небольшой кусочек — опять проверят.

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

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

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

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


V>>В этих технологиях аналогичное традиционно достигается через натурально перебарщивание с интерфейсами.
S>Во-первых, откуда "перебарщивание"? Вам так хочется, чтобы модуль А зависел от конкретного типа, определённого в модуле Б?

Как от кислого лимона у меня реакция на подобные вопросы...
Я, конечно, не упоротый фанат DDD-подхода, но отлично им владею и использую, среди прочих других.
Но фанаты именно DDD прямо сейчас подняли бы тебя на вилы за демонстрируемую нелепость...
(а да, вопрос на засыпку — почему DDD в этой теме? осилишь?)

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

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

На этом я точно пока остановлюсь, остальное после.
Жду работу над ошибками — что не так в твоём вопросе?
(там несложно)

Разберешься — приходи.