1. Непонятно зачем обсуждать «бессистемный танец» — ясно же что пример выдуманный, поэтому примером не является (возможно, специалисты по аборигенским танцам находят в них систему либо, если уж он совсем бессистемный можно его сгенерировать рандомно)
2. Пример с криптоалгоритмом реальный, но оказалось, что вот тут ТС не хочет использовать сформировавшийся язык предметной области. А там он сделан как композиция сравнительно маленьнких функций.
3. Пример с разбором сайта не является примером большого метода — ТС пока не привел больше пяти строк и призвал мысленно дополнить другими строками.
Я вполне готов согласиться, что бывают ситуации, когда длинные методы можно использовать, но нам так и не далось увидеть такого примера в этом топике
В моей, неидеальной вселенной, документы сами по себе работают дороже и глючнее, чем доступ к мозгу того, кто этот документ сформировал. Результатом предпроектного обследование является также изменение состояния нейронов обследующего. Часть этого изменения попадает в документ, часть — нет. Если есть доступ к этому мозгу, документ может быть хорошим подспорьем, если нет, часто делается не то.
Я не думаю, что предпроектное обследование отдельной фирмой жизнеспособно, так как непонятно, кто и как будет оценивать результат такого обследования. И как этот результат будет передаваться испольнителю. По крайней мере для обычного бизнеса, не для атомных электростанций.
— Не бывает здоровых кроликов красного цвета!
— Бывают, вот вам пример.
— Но это же белый кролик!
— А вы представьте, что он красный!
примеры с танцем и модифицированным DES-ом могут стать реальными при некотором стечении обстоятельств.
Почему вам удобнее обозначать ваш алгоритм как «модифицированный DES» вместо того, чтобы инлайнить его описание в каждом месте где вам надо употребить этот термин?
«Модифицированный DES» очень не точный термин — давайте вы сначала приведите все названия в соответствие со своими же воззрениями.
А это приводит к ещё одной интересной мысли — не стоит заниматься декомпозицией и выносить действия в отдельную метод не только когда эти действия не имеют общей цели (или имеют, но нам об этом неизвестно), но и тогда, когда действия имеют общую цель, но для осознания этого программисту потребуется больше усилий, нежели сэкономит декомпозиция.
Зачем портить существующую декомпозицию, зачем заниматья тем, в чем не разбираешься?
Точно так же глубокое изучение криптографии, вплоть до понимания что общего у round функций всех шифров (а если нет ничего общего, то это никакая не абстракция), только ради того, чтобы декомпозиция модифицированного DESa приносила пользу, а не вред,
Оно принесет пользу сразу, как только начнешь ее так называть — просто потому, что по этому термину можно полгуглить.
Как вам удалось модифицировать DES не понимая, как он устроен? Мне кажется в этом заключается безспримерная кривизна и не жизненность этого примера. Зачем сделан модифицированный DES, как именно он модифицирован и какая цел этих модификаций? Как вы будете анализировать криптоскойкость получившегося алгоритма?
Как только вы на эти вопросы начнете отвечать, вы либо поймете из каких частей сделан DES и какие у него требования, либо откажетесь от этой затеи.
Кстати, конструировать новый криптографический алгоритм без глубокого знания криптографии — это, ИМХО, запредельный ламеризм, от которого предупреждают во всех букварях.
Фактически, то, что кто-то не может декомпозировать DES, отказывается принимать устоявшуюся декомпозицию и при этом занимается его модификацией означает что он просто не на своем месте и делает хрень. Надеюсь, на самом деле вы таким не занимаетесь и пример высосан из пальца.
Итого:
— Пример с разбором сайта не является маленьким, большой не приведен
— примеры про танец и про «модифицированный DES» нереальны
Шифрование полублока, это правда не шифрование, а функция раунда. Я бы назвал при описании DESа ее функцией Фейстеля, в а модифицированном DES — назвал бы просто round функцией:
// Блочный шифр - это шифр который шифрует локи отдельно
let encryptByBlocks encryptBlock source =
source |> splitToBlocks |> map encryptBlock |> joinBlocks
// des - это блочный шифт
let des key = encryptByBlocks (encryptBlockUsingDes key)
// шифрование блока это первичная перестановка, потом шифрование
// фейстеля с использованием функции фейстеля в качестве round функции
// потом конченая перестановка
let encryptBlockUsingDes block key =
block |> initialPermutation |> encryptByFeistel feistelFunction key |> finalPermutation
// Сеть фейстеля
let encryptByFeistel roundFunction key block =
let subKeys = splitKey key
subkeys |> fold
(fun (left, right) subkey -> (right, left xor (rountFunction right)))
(splitBlock block)
// модифицированный DES это тоже блочный шифр
let modifiedDes key = encryptByBlocks (encryptBlockByModifiedDes key)
// Вместо функции фейстеля в качестве раунд фунции используем xor
let encryptBlockUsingModifiedDes block key =
block |> initialPermutation |> encryptByFeistel (^^^) key |> finalPermutation
Des собран из взаимозаменяемых частей, и эти части имеют названия. Неважно, что названия не говорящие для незнакомого с предметной областью. Главное, что они запоминаемые и просто соотнести с описанием для человека, знающего предметную область. Например, наш модифицированный DES будет тоже блочным шифром на основе сети Фейстеля где роль round функции играет xor.
Если сама сеть фейстеля будет модифицирована, то можно эту концепцию назвать «модифицированной сетью фейстеля» (например «упрощенная сеть фейстеля») или использовать понятие «product cipher»
Если мы не будем следовать принятой в предметной области декомпозиции, то тому, кто читает код, надо будет производить разбор кода чтобы соотнести с известными концепциями, вместо того, чтобы просто искать их по имени.
Итого:
1. «Модифицированный DES» — это тот же «безсистемный танец» — то есть оторванный от реальности пример, так как мы не специалисты по шифрованию и не можем его осознанно модифицировать, мы не можем судить о его непригодности к декомпозиции.
2. В реальности DES есть композиция более общих функций у которых есть свои названия и роли, только наше незнание предметной области приводит к тому, что эти названия непонятны — что ж везде свой жаргон.
3. Названия не всегда отражают назначение, иногда эта штука служит для запоминания/обозначения. Например нам удобнее говорить «лопата» а не «ручной копатель» просто потому, что так принято, и мы используем знак + для сложения.
Допустим, «Кусок1» изменяет состояние класса так, что это нарушает контракт «Куска2». Или результат вычислений «Куска1» передаётся в «Кусок2», нарушая его контракт. Как понять по названию «Куска2», какой у него контракт?
1. По какому угодно имени нельзя понять контракт можно только угадать его часть
2. Поэтому существуют способы для описания контактов кроме названия
3. Если кусок 1 не будет оформлен как функция, мы будем знать о контракте меньше
Абстракция «Зашифровать полублок» — неудачная, т.к. полублок вы дешифровать не сможете (без второго полублока)
Это как — функция берет полублок и ключ и выдает зашифрованный полублок. Так как в аргументы не входит ничего кроме этого и результат ее однозначно зависит от аргументов, то для расшифровки не надо ничего кроме полублока и ключа? Другое дело, что для шифрования блока нам надо сделать многократное последовательное перекрёстное шиповник полублоков, а не просто независимо зашифровать два полублока.
Заметьте, что уже в выделение в отдельную функцию и отделение интерфейса от имплементации помогает нам рассуждать о ее свойствах.
.
е. там внутри 1)узнать информацию о лотах закупки 2)о протоколах 3)о отзывах 4)о прогнозах 5)о поставщике, и ещё много чего
Приведите пример полностью (чтобы у закупки было более 13 свойств, с описаниями)
В очередной раз повторюсь, что там мы немного модифицируем «Функцию Фейстеля», после чего она «Функцией Фейстеля» не является,
1. В Википедии используется термин «основная функция дотирования» причем по фестеля говорится в скобках
2. Даже если вы модифицируете функцию фейстеля, вы можете назвать ее «модифицированная функция фейстеля» и любому знакомому с des станет понятно, какое место она занимает а алгоритме
И не надо. Код вы пишете, а не компилятор. С таким же успехом вы можете утверждать, а вдруг, мол, мы используем по ошибке имя не локальной переменной, а поля данных класса.
Типа «если компилятор не проверяет x пусть он не проверяет и y» — хорошая логика ;)
Если вы каждый день работаете с кодом, то поневоле вы может и выучите, что есть в «Куске1», а что в «Куске2». Но раз вы наизусть знаете алгоритм, то если содержимое «Куска1» и «Куска2» вставить в одно место, то вы всё равно найдёте нужное вам место.
Не факт — вместро ctrl+F Кусок1 придется смотреть глазами. С другой стороны, можно постепенно изучая давать более удачные обозначения.
«Кусок1», но сомневается как это повлияет на «Кусок2», заходит он в «Кусок2», а там «Подкусок1» и «Подкусок2»…
Вот тут у меня диаметрально противоположное мнение если кусок1 имеет разделение на интерфейс и реализацию, то достаточно легко узнать повлияет изменение на другие куски или нет. Например ясно, что переменная X локальная и употребляется только в данном куске. Компилятор поможет.
2. Пример с криптоалгоритмом реальный, но оказалось, что вот тут ТС не хочет использовать сформировавшийся язык предметной области. А там он сделан как композиция сравнительно маленьнких функций.
3. Пример с разбором сайта не является примером большого метода — ТС пока не привел больше пяти строк и призвал мысленно дополнить другими строками.
Я вполне готов согласиться, что бывают ситуации, когда длинные методы можно использовать, но нам так и не далось увидеть такого примера в этом топике
— Не бывает здоровых кроликов красного цвета!
— Бывают, вот вам пример.
— Но это же белый кролик!
— А вы представьте, что он красный!
Почему вам удобнее обозначать ваш алгоритм как «модифицированный DES» вместо того, чтобы инлайнить его описание в каждом месте где вам надо употребить этот термин?
«Модифицированный DES» очень не точный термин — давайте вы сначала приведите все названия в соответствие со своими же воззрениями.
Зачем портить существующую декомпозицию, зачем заниматья тем, в чем не разбираешься?
Оно принесет пользу сразу, как только начнешь ее так называть — просто потому, что по этому термину можно полгуглить.
Как вам удалось модифицировать DES не понимая, как он устроен? Мне кажется в этом заключается безспримерная кривизна и не жизненность этого примера. Зачем сделан модифицированный DES, как именно он модифицирован и какая цел этих модификаций? Как вы будете анализировать криптоскойкость получившегося алгоритма?
Как только вы на эти вопросы начнете отвечать, вы либо поймете из каких частей сделан DES и какие у него требования, либо откажетесь от этой затеи.
Кстати, конструировать новый криптографический алгоритм без глубокого знания криптографии — это, ИМХО, запредельный ламеризм, от которого предупреждают во всех букварях.
Фактически, то, что кто-то не может декомпозировать DES, отказывается принимать устоявшуюся декомпозицию и при этом занимается его модификацией означает что он просто не на своем месте и делает хрень. Надеюсь, на самом деле вы таким не занимаетесь и пример высосан из пальца.
Итого:
— Пример с разбором сайта не является маленьким, большой не приведен
— примеры про танец и про «модифицированный DES» нереальны
Для юзер стори разве на акцептанс/компонент/интегрейшен тесты
testCreateFile_shouldThrowException_whenFolderDoesNotExist
Des собран из взаимозаменяемых частей, и эти части имеют названия. Неважно, что названия не говорящие для незнакомого с предметной областью. Главное, что они запоминаемые и просто соотнести с описанием для человека, знающего предметную область. Например, наш модифицированный DES будет тоже блочным шифром на основе сети Фейстеля где роль round функции играет xor.
Если сама сеть фейстеля будет модифицирована, то можно эту концепцию назвать «модифицированной сетью фейстеля» (например «упрощенная сеть фейстеля») или использовать понятие «product cipher»
Если мы не будем следовать принятой в предметной области декомпозиции, то тому, кто читает код, надо будет производить разбор кода чтобы соотнести с известными концепциями, вместо того, чтобы просто искать их по имени.
Итого:
1. «Модифицированный DES» — это тот же «безсистемный танец» — то есть оторванный от реальности пример, так как мы не специалисты по шифрованию и не можем его осознанно модифицировать, мы не можем судить о его непригодности к декомпозиции.
2. В реальности DES есть композиция более общих функций у которых есть свои названия и роли, только наше незнание предметной области приводит к тому, что эти названия непонятны — что ж везде свой жаргон.
3. Названия не всегда отражают назначение, иногда эта штука служит для запоминания/обозначения. Например нам удобнее говорить «лопата» а не «ручной копатель» просто потому, что так принято, и мы используем знак + для сложения.
А параметры и возвращаемые значения?
Кстати, еще раз вопрос, почему «шифрование полублока» неправильный термин?
У меня никакой проблемы нет, мне достаточно powershell. А изучение, как мне кажется, лучше начинать до того, как делаете громкие заявления…
Переход на личности?
1. По какому угодно имени нельзя понять контракт можно только угадать его часть
2. Поэтому существуют способы для описания контактов кроме названия
3. Если кусок 1 не будет оформлен как функция, мы будем знать о контракте меньше
Это как — функция берет полублок и ключ и выдает зашифрованный полублок. Так как в аргументы не входит ничего кроме этого и результат ее однозначно зависит от аргументов, то для расшифровки не надо ничего кроме полублока и ключа? Другое дело, что для шифрования блока нам надо сделать многократное последовательное перекрёстное шиповник полублоков, а не просто независимо зашифровать два полублока.
Заметьте, что уже в выделение в отдельную функцию и отделение интерфейса от имплементации помогает нам рассуждать о ее свойствах.
.
Приведите пример полностью (чтобы у закупки было более 13 свойств, с описаниями)
1. В Википедии используется термин «основная функция дотирования» причем по фестеля говорится в скобках
2. Даже если вы модифицируете функцию фейстеля, вы можете назвать ее «модифицированная функция фейстеля» и любому знакомому с des станет понятно, какое место она занимает а алгоритме
Типа «если компилятор не проверяет x пусть он не проверяет и y» — хорошая логика ;)
На мой невзломанный Surface RT, пожалуйста ;0)
Не факт — вместро ctrl+F Кусок1 придется смотреть глазами. С другой стороны, можно постепенно изучая давать более удачные обозначения.
«Кусок1», но сомневается как это повлияет на «Кусок2», заходит он в «Кусок2», а там «Подкусок1» и «Подкусок2»…
Вот тут у меня диаметрально противоположное мнение если кусок1 имеет разделение на интерфейс и реализацию, то достаточно легко узнать повлияет изменение на другие куски или нет. Например ясно, что переменная X локальная и употребляется только в данном куске. Компилятор поможет.