Можно и по другому поступить: class StackSlots a size | a -> size instance StackSlots Char (S Z) instance StackSlots Int (S Z) instance StackSlots a size => StackSlots (Maybe a) (S size) class StackSlots a (S Z) => StackSlot a
>сперва сравниваем дизайны по тому, как много сценариев программы они покрывают
Что-то не понятно. Допустим у нас есть задача с N обязательными требованиями (не знаю, допустим проверка подписи XML-документа или определение стиля шрифта для конкретного слова в HTML на основании CSS). Какие же здесь могут быть "сценарии программы" -- либо решение удовлетворяет требованиям, либо нет.
>потом сравниваем по количеству кода, потребному для реализации дизайна
> Что-то не понятно. Допустим у нас есть задача с N обязательными требованиями (не знаю, допустим проверка подписи XML-документа или определение стиля шрифта для конкретного слова в HTML на основании CSS). Какие же здесь могут быть "сценарии программы" -- либо решение удовлетворяет требованиям, либо нет.
почему же? Например проверка подписи, её можно реализовать как подключаемую библиотеку, как standalone программу. В различных реализациях это может потребовать больше или меньше трудозатрат. Плюс подписи могут быть различными, и добавление новой технологии к программе тоже можно рассматривать как сценарий (в данном случае жизненного цикла программы). В более обширных программах таких вопросов будет ещё больше.
К тому же в дополнение к обязательным требованиям часто могут встречаться дополнительные требования, о которых можно предположить ещё на этапе проектирования, и тут опять возникает вопрос нужно ли учитывать и как учитывать их при дизайне продукта.
Может, я не умею читать, но скажу грубое: я не понял задачу. Решение вижу - реализация форта, со всякими интересными свойствами. Вопрос: для чего она делается? 1. Выполнять фортовские программы? 2. Проверять фортовские программы? 3. Кодогенерить из форта? 4. Кодогенерить в форт?
В целом, ты все правильно понимаешь. "Дизайн" проверяется наложением на предлагаемую структуру набора юзкейсов/сценариев, и расписыванием последовательности взаимодействия элементов структуры для выполнения каждого сценария. Можно делать в уме, можно фиксировать результат в виде UML Sequence Diagram. Для начала - надо фиксировать в виде картинки, пока привычка не появится.
Полезные советы. Так как юзкейсов бывает много, для архитектурной работы их полезно побить на классы, и выбрать по одному характерному представителю каждого класса. Получив, таким образом, минимально-полное множество юзкейсов, которым должен удовлетворять дизайн. Остальные - временно забыть.
Почему так. Потому, что основная выгода проектирования - в том, что получившаяся структура позволит снизить стоимость последующих правок. Возможно - по заранее неизвестным требованиям, которые появятся в будущем. Если не ставить такой цели - то можно ничего особо не дизайнить, толку один хрен не будет
( ... )
Я больше высказываю критику чужих мнений, чем рассказываю, как правильно. Да и что я рассказал-то: что можно один дизайн сравнить с другим и получить результат "лучше-хуже".
Косвенно от объёма кода стоимость правок зависит. Хотя согласен, что это всего лишь один из параметров и, наверное, не сильно важный. Тут ещё не определился.
За "развёрнутый комментарий" отдельное спасибо! После подобных твоих комментариев у меня многое в голове на место становится :)
Comments 59
Reply
Reply
Reply
class StackSlots a size | a -> size
instance StackSlots Char (S Z)
instance StackSlots Int (S Z)
instance StackSlots a size => StackSlots (Maybe a) (S size)
class StackSlots a (S Z) => StackSlot a
Это даже логичней.
Reply
Что-то не понятно. Допустим у нас есть задача с N обязательными требованиями (не знаю, допустим проверка подписи XML-документа или определение стиля шрифта для конкретного слова в HTML на основании CSS). Какие же здесь могут быть "сценарии программы" -- либо решение удовлетворяет требованиям, либо нет.
>потом сравниваем по количеству кода, потребному для реализации дизайна
Крайне спорный критерий, имхо.
Reply
почему же? Например проверка подписи, её можно реализовать как подключаемую библиотеку, как standalone программу. В различных реализациях это может потребовать больше или меньше трудозатрат. Плюс подписи могут быть различными, и добавление новой технологии к программе тоже можно рассматривать как сценарий (в данном случае жизненного цикла программы). В более обширных программах таких вопросов будет ещё больше.
К тому же в дополнение к обязательным требованиям часто могут встречаться дополнительные требования, о которых можно предположить ещё на этапе проектирования, и тут опять возникает вопрос нужно ли учитывать и как учитывать их при дизайне продукта.
Reply
1. Выполнять фортовские программы?
2. Проверять фортовские программы?
3. Кодогенерить из форта?
4. Кодогенерить в форт?
Reply
Можно потом присоединить и кодогенерацию в Форт.
Reply
Reply
А зачем тебе делать dup флагу?
Reply
В целом, ты все правильно понимаешь. "Дизайн" проверяется наложением на предлагаемую структуру набора юзкейсов/сценариев, и расписыванием последовательности взаимодействия элементов структуры для выполнения каждого сценария. Можно делать в уме, можно фиксировать результат в виде UML Sequence Diagram. Для начала - надо фиксировать в виде картинки, пока привычка не появится.
Полезные советы. Так как юзкейсов бывает много, для архитектурной работы их полезно побить на классы, и выбрать по одному характерному представителю каждого класса. Получив, таким образом, минимально-полное множество юзкейсов, которым должен удовлетворять дизайн. Остальные - временно забыть.
Почему так. Потому, что основная выгода проектирования - в том, что получившаяся структура позволит снизить стоимость последующих правок. Возможно - по заранее неизвестным требованиям, которые появятся в будущем. Если не ставить такой цели - то можно ничего особо не дизайнить, толку один хрен не будет ( ... )
Reply
А за столь развёрнутый комментарий спасибо. ;)
Reply
А в критерии сравнения у тебя неточность. Минимальный объем кода для текущего набора требований - хреновый критерий.
Объем кода конечно кореллирует с трудозатратами. Но минимум на практике для текущего набора требований достигается на крайне херовых дизайнах.
В дизайне имеет значение не только стоимость реализации, но и стоимость последующих правок. Обычно, чтобы ее снизить, в начале надо немного доплатить.
Reply
За "развёрнутый комментарий" отдельное спасибо! После подобных твоих комментариев у меня многое в голове на место становится :)
Reply
Leave a comment