Здравствуйте, Real 3L0, Вы писали:
R3>Как я думаю сделать: кубик 1 запрашивает данные А, система смотрит, кто может предоставить данные А — это кубик 2, выполняет кубик 2 — получаем данные А, отдаём данные А кубику 1. Т.е. для получения данных мне всё равно нужна сущность — кубик 2. Как в этом случае должна исчезнуть одна сущность? R3>Или это как с примером про чтение почты: кубик 1 запросил почту, кубик 2 предоставил почту, что в итоге даёт нам, что кубику 1 не надо знать о существовании сущности "MIME"?
Речь не об этом. Есть задача при изменении состояния кубика 1 изменить состояние кубика 2. При решении в общепринятом (сеттерном) стиле, если состояние кубика 1 меняется в десяти местах, то в каждом из этих мест нужно написать код меняющий состояние кубика 2. Соответственно в программе появилось десять дополнительных сущностей (например, вызовов функции обновления состояния кубика 2). Если эту же задачу решить в геттерном стиле, т.е. реализовать кубик 2 в виде автоматического кэша зависящего от кубика 1, то при изменении состояния кубика 1 вызовов функции меняющей состояние кубика 2 писать будет не нужно. Соответственно в программе станет на 10 сущностей меньше.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, DarkGray, Вы писали:
DG>>foreach, using, linq, var и т.д. — это всё как раз уменьшение кол-ва сущностей, и это синтаксический сахар S>Вообще всё в языках программирования — синтаксический сахар. В некотором смысле.
согласен.
зы
бывает еще очень хороший синтаксический сахар, например, язык C по сравнению с asm-ом, такой сахар позволяет полностью(почти) не думать о сущностях с уровня ниже, и этим обеспечивается качественный переход, а называют это что-то типа "введение уровня абстракции" (не получилось слова лучше подобрать).
и бывает что "введение уровня абстракции" противопоставляют синтаксическому сахару, хотя по сути одно продолжение другого
Здравствуйте, Ziaw, Вы писали:
Z>Процессы либо укладываются в пару-тройку кнопок, из которых составлять кубик бессмысленно, либо различаются в различных деталях, которые вынести в настройки кубика я могу, но вряд-ли кто-то еще сможет ими воспользоваться. Прекрасный пример кубиков это шелл. Именно потому, что конструирование происходит в тексте.
А если решить проблему — чтобы кто-то ещё смог ими воспользоваться?
Z>Ну да. И такие кубики себя прекрасно зарекомендовали. А вот графические конструкторы все как один убоги.
Т.е. надо придумать хороший графический конструктор?
U>Ты путаешь количество сущностей в языке и количество сущностей в программе. Стремиться надо ко второму, а не к первому.
стремиться необходимо уменьшить и первое, и второе — мозг человека не бесконечен
а плохо подобранный набор сущностей очень быстро комбинаторно взрывается, и не влазит в человеческий мозг
Здравствуйте, Undying, Вы писали:
U>Речь не об этом. Есть задача при изменении состояния кубика 1 изменить состояние кубика 2. При решении в общепринятом (сеттерном) стиле, если состояние кубика 1 меняется в десяти местах, то в каждом из этих мест нужно написать код меняющий состояние кубика 2. Соответственно в программе появилось десять дополнительных сущностей (например, вызовов функции обновления состояния кубика 2). Если эту же задачу решить в геттерном стиле, т.е. реализовать кубик 2 в виде автоматического кэша зависящего от кубика 1, то при изменении состояния кубика 1 вызовов функции меняющей состояние кубика 2 писать будет не нужно. Соответственно в программе станет на 10 сущностей меньше.
Я погуглил, но не нашел, что такое "автоматический кеш"?
Это не наследование получается?
Здравствуйте, DarkGray, Вы писали:
DG>ты совсем упускаешь, что необходимо еще постоянно доказывать правильность работы программы, особенно после каждого изменения кода
Это ты к чему? Я писал, что есть решения которые позволяют увеличить производительность программиста в разы и сократить количество ошибок на порядок, обсудить эти решения мне было бы интересно, а есть решения выигрыш от которых надо разглядывать под микроскопом, соответственно обсуждать их толку мало. В ответ ты мне приводишь пример с гипотетическим микроскопическим выигрышем. Смысл это обсуждать?
Второе, вот ты привел в пример foreach и using. Какие способы упрощения кода применены в этих конструкциях? В случае foreach применен паттерн Фасад, в случае using вынесение дублирующегося кода в метод. И паттерн Фасад, и вынесение дублирующегося кода в метод это тривиальнейшие способы упрощения кода, о которых все давным давно знают. Какой смысл их обсуждать?
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, DarkGray, Вы писали:
DG>>ты совсем упускаешь, что необходимо еще постоянно доказывать правильность работы программы, особенно после каждого изменения кода
U>Это ты к чему? Я писал, что есть решения которые позволяют увеличить производительность программиста в разы и сократить количество ошибок на порядок, обсудить эти решения мне было бы интересно, а есть решения выигрыш от которых надо разглядывать под микроскопом, соответственно обсуждать их толку мало. В ответ ты мне приводишь пример с гипотетическим микроскопическим выигрышем. Смысл это обсуждать?
U>Второе, вот ты привел в пример foreach и using. Какие способы упрощения кода применены в этих конструкциях? В случае foreach применен паттерн Фасад, в случае using вынесение дублирующегося кода в метод. И паттерн Фасад, и вынесение дублирующегося кода в метод это тривиальнейшие способы упрощения кода, о которых все давным давно знают. Какой смысл их обсуждать?
То что ты описываешь, используется настолько широко, что используя это, не выдумывают названия типа "геттерный подход" или "автоматическое кэширование". В качестве ключей активно используются cчетчики версий, временные пометки, пустые объекты, и другие объекты, которые могут описывать изменяющееся со временем состояние, как в том примере с размерами формы.
Моя мама, работавшая программистом с 68-го года, знает такой прихват. А с фасадом и экстракт-методом, наверное, не знакома.
Здравствуйте, Undying, Вы писали:
R3>>Я погуглил, но не нашел, что такое "автоматический кеш"? R3>>Это не наследование получается? U>Нет, не наследование. Простенький пример использования кэша можешь здесь посмотреть: http://rsdn.static.corbina.ru/forum/design/3612218.1.aspx
DG>>ты совсем упускаешь, что необходимо еще постоянно доказывать правильность работы программы, особенно после каждого изменения кода
U>Это ты к чему? Я писал, что есть решения которые позволяют увеличить производительность программиста в разы и сократить количество ошибок на порядок, обсудить эти решения мне было бы интересно, а есть решения выигрыш от которых надо разглядывать под микроскопом, соответственно обсуждать их толку мало. В ответ ты мне приводишь пример с гипотетическим микроскопическим выигрышем. Смысл это обсуждать?
могу продолжить твою логику: getter, но не setter — это частный случай всем известного immutable-программирования. смысл это обсуждать, и трубить об на каждом углу?
U>Второе, вот ты привел в пример foreach и using. Какие способы упрощения кода применены в этих конструкциях? В случае foreach применен паттерн Фасад, в случае using вынесение дублирующегося кода в метод. И паттерн Фасад, и вынесение дублирующегося кода в метод это тривиальнейшие способы упрощения кода, о которых все давным давно знают. Какой смысл их обсуждать?
обе эти конструкции дают гарантии
например, foreach дает гарантию (с точки зрения беглого чтения листинга), что перебор элементов не зациклится, ничего не пропустит, и не упадет сам по себе
foreach также дает уменьшение сущностей, тем что перебор элементов всегда выполняется одной конструкцией, а не десятью разными для массива, списка, последовательности и т.д.
например, вот такая конструкция вышеуказанных гарантий не дает:
for (int i = 0; i < items.length - 1; ++i)
{
Console.WriteLine(items[i]);
}
с using-ом тоже самое, он дает гарантию, что если есть using, то ресурсы будут очищены.
зы
или другими словами, for/while вместо foreach, и try/finally вместо using-а дает возможность написать их миллионом способов, при этом 99% вариантов будут ошибочными, и лишь 1% или меньше является правильным.
в итоге, код построенный на for/while/try/finally получается менее устойчивым к опечаткам и изменениям, что увеличивает стоимость тестирования и снижает стабильность конечной программы.
ззы
для проверки является ли код for (int i = 0; i < items.length — 1; ++i) правильным — приходится вводить доп. сущности, как минимум, в голове, что увеличивает общее кол-во сущностей.
Здравствуйте, DarkGray, Вы писали:
DG>могу продолжить твою логику: getter, но не setter — это частный случай всем известного immutable-программирования. смысл это обсуждать, и трубить об на каждом углу?
Во-первых, геттерный подход ортогонален immutable-программированию. Никаких проблем в использовании геттерного подхода совместно с мутабельными объектами нет, и даже более того именно в сочетании с мутабельными объектами геттерный подход позволяет снижать сложность кода максимально.
Во-вторых, геттерный подход снижает сложность кода на порядок, соответственно лучшее понимание его тонкостей может дать очень существенный выигрыш.
В-третьих, интереснее всего мне было бы обсудить не геттерный подход (его я и так знаю), а узнать о способах снижения сложности кода мне неизвестных. Паттерн Фасад и вынесение дублирующегося кода в метод мне известны, поэтому обсуждать их неинтересно.
U>>Второе, вот ты привел в пример foreach и using. Какие способы упрощения кода применены в этих конструкциях? В случае foreach применен паттерн Фасад, в случае using вынесение дублирующегося кода в метод. И паттерн Фасад, и вынесение дублирующегося кода в метод это тривиальнейшие способы упрощения кода, о которых все давным давно знают. Какой смысл их обсуждать?
DG>обе эти конструкции дают гарантии
И толку с этого? Какую долю в общем количестве ошибок составляют ошибки при работе с for и finally? У меня исчезающе малую. И смысл это обсуждать, если 99,9% ошибок имеют совершенно другую природу?
Здравствуйте, samius, Вы писали:
S>Моя мама, работавшая программистом с 68-го года, знает такой прихват. А с фасадом и экстракт-методом, наверное, не знакома.
Т.е. твоя мама программируя не использовала функций и не вызывала одну и ту же функцию в нескольких местах программы? Серьезно? Терминов фасад и экстракт-метода твоя мама, конечно, может и не знать, но суть их явно знает прекрасно, т.к. это азы программирования, без которых решение мало-мальски серьезных задач невозможно.
Здравствуйте, samius, Вы писали:
S>То что ты описываешь, используется настолько широко, что используя это, не выдумывают названия типа "геттерный подход" или "автоматическое кэширование". В качестве ключей активно используются cчетчики версий, временные пометки, пустые объекты, и другие объекты, которые могут описывать изменяющееся со временем состояние, как в том примере с размерами формы.
Кстати, если геттерный подход это общеизвестно, то с чего это, к примеру, все микрософтовские библиотеки написаны в кошмарном сеттерном стиле?
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, samius, Вы писали:
S>>Моя мама, работавшая программистом с 68-го года, знает такой прихват. А с фасадом и экстракт-методом, наверное, не знакома.
U>Т.е. твоя мама программируя не использовала функций и не вызывала одну и ту же функцию в нескольких местах программы? Серьезно? Терминов фасад и экстракт-метода твоя мама, конечно, может и не знать, но суть их явно знает прекрасно, т.к. это азы программирования, без которых решение мало-мальски серьезных задач невозможно.
Ну как, и серьезно и не очень. Во времена молодости моей мамы такие вещи называли "подпрограммы". Т.е. фасад был из подпрограмм, и экстракт тоже подпрограмм.
Здравствуйте, DarkGray, Вы писали:
DG>могу продолжить твою логику: getter, но не setter — это частный случай всем известного immutable-программирования. смысл это обсуждать, и трубить об на каждом углу?
Вот когда хотя бы gridSynchronizer будет частью фрамеворка я поверю, что геттерный подход стал более-менее общеизвестным. А пока что во всех библиотеках кошмарная событийно-сеттерная логика, соответственно ничего общеизвестного в геттерном подходе нет, даже подавляющее большинство гиков не понимает что это такое.
Здравствуйте, samius, Вы писали:
S>Ну как, и серьезно и не очень. Во времена молодости моей мамы такие вещи называли "подпрограммы". Т.е. фасад был из подпрограмм, и экстракт тоже подпрограмм.
И к чему это буквоедство? Функция, подпрограмма, метод это синонимы, обозначающие одно и тоже, а именно некий код, который можно вызвать повторно.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, samius, Вы писали:
S>>То что ты описываешь, используется настолько широко, что используя это, не выдумывают названия типа "геттерный подход" или "автоматическое кэширование". В качестве ключей активно используются cчетчики версий, временные пометки, пустые объекты, и другие объекты, которые могут описывать изменяющееся со временем состояние, как в том примере с размерами формы.
U>Кстати, если геттерный подход это общеизвестно, то с чего это, к примеру, все микрософтовские библиотеки написаны в кошмарном сеттерном стиле?
Даже если посмотреть на вездесущий IEnumerable, то в его контракте заложено именно то, о чем ты выражаешься как "геттерный подход". Изменение коллекции увеличивает версию коллекции, которую кэширует перечислитель.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, samius, Вы писали:
S>>Ну как, и серьезно и не очень. Во времена молодости моей мамы такие вещи называли "подпрограммы". Т.е. фасад был из подпрограмм, и экстракт тоже подпрограмм.
U>И к чему это буквоедство? Функция, подпрограмма, метод это синонимы, обозначающие одно и тоже, а именно некий код, который можно вызвать повторно.
Совершенно ни к чему. Я же написал, что не очень серьезно.
U> Во-первых, геттерный подход ортогонален immutable-программированию.
если ты про кэши, то это частный случай lazy-программирования
U>Кстати, если геттерный подход это общеизвестно, то с чего это, к примеру, все микрософтовские библиотеки написаны в кошмарном сеттерном стиле?
проще обеспечить меньшее кол-во оверхеда и наведенных эффектов.
например, ты в курсе, что на lazy-инициализации легко словить зацикленность и stackoverflow?
