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

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

E>>>Есть модульность (Modularity).
T>>

Modular programming is a software design technique that increases the extent to which software is composed from separate parts, called modules. Conceptually, modules represent a separation of concerns, and improve maintainability by enforcing logical boundaries between components.

E>>>Есть связанность (Coupling).

E>>>Ты, похоже, трактуешь модульность в смысле связности.

T>>Трактовка википедии недалеко ушла от моей.

E>

E>Модульность, по-моему, степень независимости при разработке отдельных частей системы.

E>Похоже, я многое в этой жизни пропустил, поскольку теперь "степень независимости" является синонимом "software design technique".

Модульность это и свойство: "модульность программы", "модульность системы", например. "Высокая модульность", "низкая модульность". Да вообще можно сделать прилагательное "модульный". "Модульный дизайн программы"

Слово "модульность" само по себе, без дополняемого существительного — software design technique. Вместе с существительным — свойство этого существительного.

Не так?

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

T>Модульность это и свойство: "модульность программы", "модульность системы", например. "Высокая модульность", "низкая модульность".

Не могу понять, что означают выражения "высокая модульность" и "низкая модульность". Есть устоявшиеся термины cohesion и coupling, и для них определены high/low cohesion/coupling. Если под "высокой/низкой модульностью" ты понимаешь что-нибудь из этого, то это одно дело. А если что-то другое...

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

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

T>>Модульность это и свойство: "модульность программы", "модульность системы", например. "Высокая модульность", "низкая модульность".

E>Не могу понять, что означают выражения "высокая модульность" и "низкая модульность". Есть устоявшиеся термины cohesion и coupling, и для них определены high/low cohesion/coupling. Если под "высокой/низкой модульностью" ты понимаешь что-нибудь из этого, то это одно дело. А если что-то другое...

http://rsdn.ru/forum/philosophy/3444207.1.aspx

Автор: thesz
Дата: 26.06.09

J>The main advantage of named state is that the program becomes modular. The main disadvantage is that a program can become incorrect.

max(модульность) ≡ min(взаимозависимость).

min(взаимозависимость) ≡ min(вероятность ошибки при изменении части).

Пожалуй, я не виноват в том, что автор исходной цитаты использовал термин modular.

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

Поэтому я считаю, что цитата неверна (содержит противоречие) вне зависимости от нашего расхождения в понимании термина модульность.

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

E>Здравствуйте, Курилка, Вы писали:

E>>>Есть модульность (Modularity).
E>>>Есть связанность (Coupling).

E>>>Ты, похоже, трактуешь модульность в смысле связности.

К>>По-моему ты тут зачем-то противопоставляешь 2 очень взаимосвязных термина: модульность говорит о том, что прогамма "побита" на части, т.е. модули, так вот внутри этих модулей хорошая связность, а между ними она должна быть минимальной для реализации separation of concerns.

E>Еще раз: модульность -- это подход к разработке ПО, при котором система строится из модулей со строго определенными внешними интерфейсами, а детали модулей скрыты внутри и недоступны снаружи. Поэтому само понятие max(модульность) для меня выглядит странным. Надо полагать, что max(модульность) -- это "хороший дизайн", а это очень субъективно.

Мы можем соответствовать подходу в большей или меньшей степени. Эта оценка субъективна, согласен.

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

E>Связность как раз показывает степень взаимосвязи между компонентами системы. И как раз у связности можно определять min и max.

При повышении модульности мы снижаем связность и наоборот, так?


E>Ну и кроме того, когда речь заходит о "степени независимости", то значит разговор идет именно о "связности", а не о "модульности" (если брать за основу определения из Wikipedia).

It's the dreaded "the program becomes modular".

К>>Правда, вот с Хаскелем ситуация выходит, что даже отдельные функции становятся модулями, если не рассматривать классы типов.
E>Это проблемы Хаскеля.

Это достоинство Хаскеля.

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

T>

J>The main advantage of named state is that the program becomes modular. The main disadvantage is that a program can become incorrect.

T>max(модульность) ≡ min(взаимозависимость).

T>min(взаимозависимость) ≡ min(вероятность ошибки при изменении части).

T>Пожалуй, я не виноват в том, что автор исходной цитаты использовал термин modular.

Ну ты же указал тождество между max(модульность) и min(взаимозависимость). Оно мне не понятно, поскольку под max(модульность) можно понимать разные вещи. В моем представлении, max(модульность) -- это соотношение количества модулей к объему программы. Т.е., чем на большее количество модулей разбита система, тем больше модульность. Но!

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

Т.е. твое тождество можно воспринимать как цель, к которой нужно стремиться. Но не факт, что она достижима в условиях ограниченного времени и ресурсов.

T>Я не считаю, что для программы с именованным состоянием уменьшается связность.

Я тоже так не считаю.

T>Поэтому я считаю, что цитата неверна (содержит противоречие) вне зависимости от нашего расхождения в понимании термина модульность.

У меня сложилось впечатление, что вывод "The main advantage of named state is that the program becomes modular." в обсуждаемой статье вообще не был доказан. Был приведен какой-то мутный пример и все.

E>Т.е. твое тождество можно воспринимать как цель, к которой нужно стремиться. Но не факт, что она достижима в условиях ограниченного времени и ресурсов.

Там ещё есть, кроме модульности.

T>>Я не считаю, что для программы с именованным состоянием уменьшается связность.

E>Я тоже так не считаю.

T>>Поэтому я считаю, что цитата неверна (содержит противоречие) вне зависимости от нашего расхождения в понимании термина модульность.

E>У меня сложилось впечатление, что вывод "The main advantage of named state is that the program becomes modular." в обсуждаемой статье вообще не был доказан. Был приведен какой-то мутный пример и все.

Я рад, что мы пришли к общему мнению.

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

E>В моем представлении, max(модульность) -- это соотношение количества модулей к объему программы. Т.е., чем на большее количество модулей разбита система, тем больше модульность. Но!

Орррррррригинально.
Тот факт, что такое определение не имеет абсолютно никакого смысла, не напрягает?

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

E>>В моем представлении, max(модульность) -- это соотношение количества модулей к объему программы. Т.е., чем на большее количество модулей разбита система, тем больше модульность. Но!

VE>Орррррррригинально.

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

VE>Тот факт, что такое определение не имеет абсолютно никакого смысла, не напрягает?

Когда я еще учился программировать преподаватель рассказывал, что он застал повальное увлечение структурным и модульным программированием. Которое временами принимало оригинальные формы, как то -- полный запрет на использование глобальных переменных, оператора goto и жестких ограничений на объем модуля (скажем, 3K строк). И если твой модуль оказывался на 10 строчек больше объявленного предела, тебе приходилось его разбивать на два более мелких.

Я сам столкнулся с более современным проявлением этого подхода. Мной был написан транслятор из специализированного языка в Java и этот транслятор генерировал java-файлы в десятки тысяч строк. Когда такой файл приходил на code review, мы сразу же получали официальное замечание -- мол, отрефакторите свой класс XXX. А то у него код слишком большой, во много раз превышающий рекомендуемый объем. Мы объясняли, что этот файл генерируется автоматически, замечение снимали. Но до тех пор, пока файл не попадал на глаза другому code reviewe
r-у. Который сразу же выдвигал официальное замечание (никто почему-то не обращал внимание на комментарии вначале сгенерированного файла).

Так что количество смысла в данном определении сильно зависит от степени маразма читателя

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

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

E>Каждый думает в меру своей распущенности. Если объем программ или выхлоп программиста зачастую измеряют в KLoc, то почему бы аналогичным образом не изменять модульность?

В принципе-то конечно можно.
Но если говорить о данном конкретном случае (а именно фразе на английском), то не понимаю, как наличие named state влияет на количество модулей.

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

E>>Каждый думает в меру своей распущенности. Если объем программ или выхлоп программиста зачастую измеряют в KLoc, то почему бы аналогичным образом не изменять модульность?

VE>В принципе-то конечно можно.
VE>Но если говорить о данном конкретном случае (а именно фразе на английском), то не понимаю, как наличие named state влияет на количество модулей.

Я вообще не понимаю, почему автор статьи решил, что наличие named state каким-то образом влияет на улучшение модульности.

А дальше началось наше с thesz разногласие по поводу того, какой смысл вкладывается в "модульность". Поскольку у меня были свои представления о том, что может означать "max(модульность)" (и это не то, что min/max(coupling)), а у thesz -- свои. Но это разногласие не имеет отношения к процитированной английской фразе, а всего лишь следствие заочного общения по переписке.

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

T>

A component without named state, once proved correct, always stays correct. Correctness is not so simple to maintain for a component with named state. A good rule is that named state should never be <b>in</b>visible: there should always be some way to access it from the outside.

T>- Подход Эрланга — я могу передать значение части состояния куда-либо, но извне оно не видно, — скорее удовлетворяет условию, чем наоборот.

А ты уверен, что всё правильно прочитал и понял?

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

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

T>>

A component without named state, once proved correct, always stays correct. Correctness is not so simple to maintain for a component with named state. A good rule is that named state should never be <b>in</b>visible: there should always be some way to access it from the outside.

T>>- Подход Эрланга — я могу передать значение части состояния куда-либо, но извне оно не видно, — скорее удовлетворяет условию, чем наоборот.

AF>А ты уверен, что всё правильно прочитал и понял?

Да. А ты?

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

T>Да. А ты?

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

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

AF>Почему подход Эрланга "я могу передать значение части состояния куда-либо, но извне оно не видно, — скорее удовлетворяет условию" — если в исходном утверждении сказано "состояние никогда не должно быть невидимым"?
В исходном утверждении жирным выделено другое.

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

VE>В исходном утверждении жирным выделено другое.

Ну и что? Я выделил ту часть, которая явно была понята неправильно.

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

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

VE>>В исходном утверждении жирным выделено другое.

AF>Ну и что? Я выделил ту часть, которая явно была понята неправильно.

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

Какому условию, с твоей точки зрения, подход Эрланга не удовлетворяет, процитируй его.

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

VE>Какому условию, с твоей точки зрения, подход Эрланга не удовлетворяет, процитируй его.

Я это условие специально жирным выделил. Оно не просто "не удовлетворяет" — оно ему противоположно. Или например здесь: "Объекты удовлетворяли бы этому условию, если бы не могли дать доступ к частям внутреннего состояния". Сравни с "state should never be invisible"
Ты и thesz — один и тот же человек, не так ли?

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

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

VE>>Какому условию, с твоей точки зрения, подход Эрланга не удовлетворяет, процитируй его.

AF>Я это условие специально жирным выделил. Оно не просто "не удовлетворяет" — оно ему противоположно. Или например здесь: "Объекты удовлетворяли бы этому условию, если бы не могли дать доступ к частям внутреннего состояния". Сравни с "state should never be invisible"
А теперь внимательно ещё раз прочти его пост и посмотри условие, которое выделил он.
А потом ещё прочти мой пост. Двух раз должно быть достаточно.
Я гляжу в моду уже вошло брать другое условие (противоположное причём) и оспаривать несоответствие утверждений этому новому условию.
AF>Ты и thesz — один и тот же человек, не так ли?
Нет, я просто читать умею.

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

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

T>>Да. А ты?

AF>Почему подход Эрланга "я могу передать значение части состояния куда-либо, но извне оно не видно, — скорее удовлетворяет условию" — если в исходном утверждении сказано "состояние никогда не должно быть невидимым"?

Тут возможно так много ответов, что я смущён обилием вариантов.

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

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

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

T>Укажи, где в исходном утверждении находится фраза "состояние никогда не должно быть невидимым" или её перевод на английский.

Re[11]: Почему монады лучше lvalue (глобальных переменных).