Сохранение и восстановление состояния обработки
 |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
| ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
| [18.223.134.29] |
|
|
Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
| Страницы: (12) « Первая ... 5 6 [7] 8 9 ... 11 12 все ( Перейти к последнему сообщению ) |
Сохранение и восстановление состояния обработки
|
Сообщ.
#91
,
|
  |
Common Lisp на goto:
Прикреплённый файл  majestio_machine.lisp.zip (853 байт, скачиваний: 34)
Добавлено Никакой портянки. Вот когда требования изменятся, тогда и будешь тратить время на рефакторинг. YAGNI Цитата Wound @ Потом в итоге это дойдет до условного потолка, когда поддерживать это будет боль и ад. Рефакторить нужно вовремя. Цитата Wound @ Тем более что: Цитата Majestio @ 12 сентября, 21:06 Ну пусть будем думать, что процессов не 4, а 50. Ну так, на перспективу Если у тебя 50 процессов, никак не сгруппированных в подсистемы, то у тебя в любом случае будет жопа, хоть switch/case'ом пиши, хоть объектами, хоть наглядную схему черти: запутаешься в переходах от объекта к объекту, и общая картина у тебя не соберётся в голове. Цитата Wound @ А если таких процессов скажем не 4 и не 50, а неизвестно сколько заранее - то тут с этим свичем пролетаешь. А если метеорит упадёт на датацентр? Тут ничего не пролетает. Цитата Wound @ при условии что ТС обозначил еще 50 процессов на перспективу, он же полюбому в свою архитектуру с goto закладывал такой вариант, раз про него написал. ТСу надо пересмотреть архитектуру проекта в первую очередь, в таком случае. А goto тут не при чём. |
|
Сообщ.
#92
,
|
|
 |
Цитата korvin @ Никакой портянки. Портянка и спагети-код, к бабке не ходи. Цитата korvin @ Вот когда требования изменятся, тогда и будешь тратить время на рефакторинг. YAGNI Не не не, то что я озвучил - никак не нарушает принцип YAGNI, просто сам подход и архитектура - закладывается с таким прицелом, чтоб это потом проще было бы расширять и сопровождать. А не переписывать с нуля каждый раз. Цитата korvin @ Рефакторить нужно вовремя А есть какие то четкие критерии? Ты вот сделал для 5 процессов свой switch, завтра тебе скажут - у нас тут еще 2 процесса добавилось, ты их добавишь, потом тебе придут скажут - еще один, потом еще 2, и начиная со скольки ты задумаешься о том, что твой switch тебя уже порядком начал напрягать и порабы это все отрефакторить? Цитата korvin @ Если у тебя 50 процессов, никак не сгруппированных в подсистемы, то у тебя в любом случае будет жопа, хоть switch/case'ом пиши, хоть объектами, хоть наглядную схему черти: запутаешься в переходах от объекта к объекту, и общая картина у тебя не соберётся в голове. У меня точно жопы не будет, т.к. каждый процесс - рассматривается как отдельная сущность. И соответственно нет смысла рассматривать его в контексте всей системы. Вот когда само условие задачи изменится так, что сам процесс перестанет иметь смысл, вот тогда возможно мне и придется чего то пересматривать. А до этого - мне не нужно держать общую картину в голове. Цитата korvin @ А если метеорит упадёт на датацентр? Так это не что то из ряда вон выходящее, а вполне себе суровая реальность. Цитата korvin @ Тут ничего не пролетает. Ну разве что если сидеть выносить себе мозги этим goto... Цитата korvin @ ТСу надо пересмотреть архитектуру проекта в первую очередь. А goto тут не при чём. Ну я пока не видел его решения, может быть ему не придется ничего пересматривать, откуда я знаю. Добавлено Ну и плюс расписать всю его схему на if/else или switch|case - много ума не надо(это даже не интересно), я сразу же отказался от этого варианта, т.к. это сложнее, чем тот подход, который например, я выбрал. Про другие подходы - я не говорю, т.к. не видел. |
|
|
Сообщ.
#93
,
|
|
|
Цитата Wound @ закладывается с таким прицелом, чтоб это потом проще было бы расширять и сопровождать. Это и есть нарушение принципа YAGNI. Это «потом расширять» может никогда не наступить и в итоге у тебя overengineering на ровном месте. Цитата Wound @ А есть какие то четкие критерии? Ты вот сделал для 5 процессов свой switch, завтра тебе скажут - у нас тут еще 2 процесса добавилось, ты их добавишь, потом тебе придут скажут - еще один, потом еще 2, и начиная со скольки ты задумаешься о том, что твой switch тебя уже порядком начал напрягать и порабы это все отрефакторить? Более-менее есть: Цитата Каждый программист знает, что возможности нашего мозга не безграничны. Есть ограничение на количество вещей, о которых мы можем думать. Это наш рабочий лимит памяти. Есть старый миф о том, что человек может держать в памяти одновременно 7±2 объектов. Это называется "Магическое число семь" и оно на самом деле не очень точное. Последние исследования говорят о числе 4±1, а то и меньше. В любом случае — количество идей, которые мы можем держать одновременно в голове, весьма ограниченно. Цитата Wound @ У меня точно жопы не будет, т.к. каждый процесс - рассматривается как отдельная сущность. Но 1) он не отдельный: после него идёт проверка по результатам которой выбирается следующий процесс — вот тебе и связь. Только ты раскидал её по разным файлам. Теперь, чтобы восстановить картину, тебе понадобится сгенерировать какую-нибудь диаграмму классов/зависимостей, а ля UML, вместо того, чтобы сразу написать наглядный код. 2) ничто не мешает мне вынести реализации процессов в отдельные процедуры, что я ± и сделал в своих примерах, сохранив при этом общую схему в одном месте, прям как на картинке.   case 1: process1(); state = decision1() ? 4 : 3; break; Ну а мой пример на Go позволяет так же всё довольно легко расщирять, при желании/необходимости и/или сохранять схему в одном месте. Цитата Wound @ Так это не что то из ряда вон выходящее, а вполне себе суровая реальность. Падающие на датацентры метеориты — суровая реальность? Цитата Wound @ Ну разве что если сидеть выносить себе мозги этим goto... Там нечем выносить. Применение goto там ничем не отличается от switch/case. Цитата Wound @ Ну я пока не видел его решения, может быть ему не придется ничего пересматривать, откуда я знаю. Архитектура «диктует» решение, а не наоборот. Добавлено Цитата Wound @ Ну и плюс расписать всю его схему на if/else или switch|case - много ума не надо(это даже не интересно), я сразу же отказался от этого варианта, т.к. это сложнее Ты сам себе противоречишь: определись, «много ума не надо» или «сложнее». Цитата Wound @ это сложнее, чем тот подход, который например, я выбрал. Твоё решение — 92 килобайта, решение ТС — меньше килобайта. Расскажи ещё раз про сложность. |
|
Сообщ.
#94
,
|
|
|
|
Цитата korvin @ Это и есть нарушение принципа YAGNI. Это «потом расширять» может никогда не наступить и в итоге у тебя overengineering на ровном месте. Судя по описанию в вики, принцип YAGNI нарушается тогда, когда ты делаешь то, что тебе нахер не упало, но по твоим ощущениям в будущем может пригодится. Например в моем подходе таких функций/методов нет. Там все нужно. А то тебя щас послушаешь, так выйдет так что и принципы SOLID противоречат YAGNI, и вообще все надо писать в main, спагети-кодом, а потом когда заказчик прибежит с очередными требованиями - срочно надо все рефакторить и обязательно снова спагети-кодом, а как иначе? Зачем усложнять да? Цитата korvin @ Более-менее есть: Ну тогда switch тут вообще не катит, последние же иследования говорят что 4+- 1, а у тебя аж 5 процессов в исходной задаче, вместе с default - 6  Цитата korvin @ 1) он не отдельный: после него идёт проверка по результатам которой выбирается следующий процесс — вот тебе и связь. Только ты раскидал её по разным файлам. Теперь, чтобы восстановить картину, тебе понадобится сгенерировать какую-нибудь диаграмму классов/зависимостей, а ля UML, вместо того, чтобы сразу написать наглядный код. А зачем мне ее востанавливать, если я делал по уже созданной схеме? Это какой то реверс-инжиниринг? Тогда даже в этом случае - понять что происходит у меня будет проще, чем с goto тем же. Если ты внимательно посмотришь - там кода на строчек 15-20, все остальное это всякие проверки, исключения и тело класса. А че, пустой класс с конструктором уже около 10 строк занимает. Цитата korvin @ 2) ничто не мешает мне вынести реализации процессов в отдельные процедуры, что я ± и сделал в своих примерах, сохранив при этом общую схему в одном месте, прям как на картинке. Ну так после ивента ТС скажет, а давайте теперь еще 45 процессов добавим, чтоб 50 получилось. И вся твоя наглядность рухнет, потому что как ты там выше написал чел больше 4 вещей одновременно воспринимать не может. А у тебя их 50. Цитата korvin @ Падающие на датацентры метеориты — суровая реальность? Суровая реальность когда система постоянно расширяется, и дополняется. Выдвигают новые условия, новые фичи и т.д. Цитата korvin @ Там нечем выносить. Применение goto там ничем не отличается от switch/case. Искать метку глазами, в незнакомом коде - то еще удовольствие, если тебе такой подход нравится - дело твое, я ж ниче против не имею. Только не нужно это преподносить как общепринятую практику. Цитата korvin @ Архитектура «диктует» решение, а не наоборот. Вообще не понял о чем ты тут. Я написал что - я не видел что сделал ТС. И не могу прогнозировать придется ему там все переписывать с нуля, или просто добавить еще с десяток меток. Добавлено Цитата korvin @ Ты сам себе противоречишь: определись, «много ума не надо» или «сложнее». Много ума не надо, а сложнее в том, что все это превращается в спагети-код. Цитата korvin @ Твоё решение — 92 килобайта, решение ТС — меньше килобайта. Расскажи ещё раз про сложность. Я тебе в личку скинул пароль от своего архива. Если бы ты его скачал и посмотрел что там, может быть ты бы понял почему там 92 килобайта. Добавлено Цитата korvin @ Теперь, чтобы восстановить картину, тебе понадобится сгенерировать какую-нибудь диаграмму классов/зависимостей, а ля UML, вместо того, чтобы сразу написать наглядный код. Ну и плюс в MSVS есть диаграмма классов, которую можно сгенерировать из уже написаной проги. Я вот ради прикола сгенерировал. Прекрасно востановилась схема ТС. Могу скинуть скрин если нужно. |
|
|
Сообщ.
#95
,
|
|
|
Цитата Wound @ Ну тогда switch тут вообще не катит, последние же иследования говорят что 4+- 1, а у тебя аж 5 процессов в исходной задаче, вместе с default - 6 Где из пять? Их четыре, stop/default — не процесс. И не нужно понимать всё буквально. Добавлено Цитата Wound @ Много ума не надо, а сложнее в том, что все это превращается в спагети-код. Нет, не превращается. Беготня по классам-родителям-наследникам туда-сюда — вот настоящее спагетти =) Добавлено Цитата Wound @ Ну и плюс в MSVS есть диаграмма классов, которую можно сгенерировать из уже написаной проги. Нет, чтобы код писать понятный, лучше добавить костыль, да? |
|
Сообщ.
#96
,
|
|
|
|
Цитата korvin @ Где из пять? Их четыре, stop/default — не процесс. И не нужно понимать всё буквально. Я изначально сделал 4, мне Majestio написал, сказал пятый тоже надо. Я выложил второй архив, чтоб максимально соответствовало условию. Но не суть важно. Цитата korvin @ Нет, не превращается. Беготня по классам-родителям-наследникам туда-сюда — вот настоящее спагетти =) Да ну, какая беготня? Я если честно не понимаю твоих аргументов. Добавлено Цитата korvin @ Нет, чтобы код писать понятный, лучше добавить костыль, да? А код проще некуда, и это к слову не костыль, особенно когда у тебя не хеловорлд, а огромный проект. Чтоб не рисовать схемки в тетрадочке, две кнопки ткнул, и смотришь связи. |
|
|
Сообщ.
#97
,
|
|
|
Цитата Wound @ Искать метку глазами, в незнакомом коде - то еще удовольствие Что там искать? Там код десять строчек. А искать ту реализацию метода интерфейса, которая действительно была вызвана, — вот это настоящее приключение. Добавлено Цитата Wound @ Я тебе в личку скинул пароль от своего архива. Если бы ты его скачал и посмотрел что там, может быть ты бы понял почему там 92 килобайта. А я скачал и посмотрел: куча бойлерплейта, и всякие вспомогательные файлы студии. |
|
Сообщ.
#98
,
|
|
|
|
Цитата korvin @ Что там искать? Там код десять строчек. А искать ту реализацию метода интерфейса, которая действительно была вызвана, — вот это настоящее приключение. Да то там искать, как не вижу goto, а я довольно редко его встречаю, в основном в индусских примерах WinAPI на MSDN'e, так сидишь смотришь - где там этот индус метки понаставил, и каким хером я туда попаду, и почему я не попаду в другое место. И вроде кода 40 строк, а сидишь как олень метки эти ищешь. И про какую ту реализацию метода ты говоришь? В чем у тебя проблемы с поиском методов я не понимаю? |
|
|
Сообщ.
#99
,
|
|
|
Цитата Wound @ Да ну, какая беготня? Я если честно не понимаю твоих аргументов. Что, никогда стектрейсы фреймворков с DI-контейнерами не разгребал, например? ) |
|
Сообщ.
#100
,
|
|
|
|
Цитата korvin @ А я скачал и посмотрел: куча бойлерплейта, и всякие вспомогательные файлы студии. Ну так вот тебе и ответ откуда там 92 килобайта. Уж извини не я делал плюсы и всякие сишарпы, но с другой стороны и руками я его не писал, IDE все само генерило. Добавлено Цитата korvin @ Что, никогда стектрейсы фреймворков с DI-контейнерами не разгребал, например? ) А причем тут что я разгребал и то что мы обсуждаем? Я тебе могу тоже задать вопрос ты что никогда спагети-код написанный в стиле ассемблера, с максимальной длиной переменных и идентификаторов в две с половиной буквы и кучей к месту и не к месту меток, не разгребал? |
|
|
Сообщ.
#101
,
|
|
|
Цитата Wound @ А причем тут что я разгребал и то что мы обсуждаем? Я тебе могу тоже задать вопрос ты что никогда спагети-код написанный в стиле ассемблера, с максимальной длиной переменных и идентификаторов в две с половиной буквы и кучей к месту и не к месту меток, не разгребал? Да при том, что спагеттность зависит не от того, используешь ты goto или объекты, а от плохой структурированности архитектуры приложения. Попробуй добавить ещё 45 процессов и ветвлений (decision), и сгенерировать схему. Можешь приложить скриншот сюда — посмотрим, сколько там будет стрелок и их пересечений. |
|
Сообщ.
#102
,
|
|
|
|
Цитата korvin @ Попробуй добавить ещё 45 процессов и ветвлений (decision), и сгенерировать схему. Можешь приложить скриншот сюда — посмотрим. Ну во первых мне честно лень добавлять еще 45 процессов. Это тупая копипаста получится. Схема от этого особо не изменится, если ты заметил у меня возвращается там не просто строка, а поле класса, генератор построит примерно такую же блоксхему как на твоем скрине, т.к. каждый объект решения будет ссылаться на соответствующие процессы, единственное что там не будет писать Yes/No, но связи понятны будут. Вот пример того что сгенерировалось на том, что уже там есть: Скрытый текст Прикреплённая картинка
Добавлено Цитата korvin @ Да при том, что спагеттность зависит не от того, используешь ты goto или объекты, а от плохой структурированности архитектуры приложения. Как показывает практика и мой личный опыт, практически в 99% случаев код с goto - представляет из себя спагети-код. Добавлено Еще в Сях так или иначе goto можно оправдать когда надо вылететь из -за МКАДа куда то в конец функции на Cleanup, и то это не всегда оправдано. А уж в плюсах - этот goto нахрен не упал, ИМХО. |
|
|
Сообщ.
#103
,
|
|
|
Цитата Wound @ если ты заметил у меня возвращается там не просто строка, а поле класса И что? Цитата Wound @ Вот пример того что сгенерировалось на том, что уже там есть: Ужас какой. А вот эти *Context — они чему соответствуют на изначальной схеме? Судя по этой диаграмме все ProcessN обрывают выполнение программы. |
|
Сообщ.
#104
,
|
|
|
|
Цитата korvin @ И что? Ничего. Просто это означает что у меня из готовых классов, хоть даже их будет 50, проще будет востановить изначальную схему, чем у тебя с goto. Цитата korvin @ Ужас какой. А вот эти *Context — они чему соответствуют на изначальной схеме? Судя по этой диаграмме все ProcessN обрывают выполнение программы. Это базовая диаграмма на всякий шлак, не нужное можно выбросить и оставить только нужное. Расположить как тебе нравится. Ужас будет когда твой switch/goto кто то будет разгребать. Вот там да - будет ужас. А например, если выкинуть весь вспомогательный шлак и отфильтровать не нужное, то в сухом остатке останется вот такая схема: Скрытый текст Прикреплённая картинка
Добавлено На картинке это конечно херово показывать, но в IDE, я сразу могу ткнуть кнопку код, и тогда, когда я тыкну на ноду Decision, мне сразу откроется ее код, в котором идет условие. Т.е. я находу могу понять когда оно будет ссылаться на один процес, а когда на другой. Соответственно схема у меня уже готовая, даже разгребать ничего не нужно. Добавлено А теперь ты покажи, как ты будешь востанавливать изначальную блоксхему из всех этих goto, особенно в каких нибудь плюсах. Вангую щас полетят "аргументы" в стиле - гляну на код, закрою глаза и сразу в мозгу схема нарисуется  |
|
|
Сообщ.
#105
,
|
|
|
Цитата Wound @ А теперь ты покажи, как ты будешь востанавливать изначальную блоксхему из всех этих goto, особенно в каких нибудь плюсах. Вангую щас полетят "аргументы" в стиле - гляну на код, закрою глаза и сразу в мозгу схема нарисуется А зачем мне «восстанавливать схему», если оно отображена в коде как есть? int main() { PROC_1 : process_1() ; if (decision_1()) goto PROC_4 ; else goto PROC_3 ; PROC_2 : process_2() ; if (decision_2()) goto PROC_3 ; else goto PROC_4 ; PROC_3 : process_3() ; if (decision_3()) goto PROC_2 ; else goto PROC_1 ; PROC_4 : process_4() ; if (decision_4()) goto EXIT ; else goto PROC_2 ; EXIT: return 0; } Странный ты, наплодил себе классов, теперь без сгенерированной диаграммы не можешь разобраться в коде ) |
0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
0 пользователей:
[ Script execution time: 0,1147 ] [ 21 queries used ] [ Generated: 9.05.24, 02:36 GMT ]