состояние возврата шаблона "команда"
-
nchar является фиксированной длиной и может содержать unicode символы. это использует двухбайтовое устройство хранения данных на символ.
-
varchar имеет переменную длину и не может содержать unicode символы. это использует однобайтовое устройство хранения данных на символ.
8 ответов
There are two questions in the question with multiple answers :) The first question is should a command return an error state?
There is no clear answer for every program every time you apply the pattern you have to think about it again.
One of the things you need to think about is:
- Am I adding more coupling to many commands and the clients for only some specific error cases?
In the worst case you have many commands that don't care about errors but one or two commands do something that is important for the client to know if it worked. You now add checked Exceptions to the Interface and so every client and every Command are bound to do error handling and are coupled to the Exception. If you have a client that only deals with commands that are not throwing the exceptions you have a big overhead in your code.
This is a thing that you don't want to have. So you can either move the commands that need error handling out of the command structure because they seem to be different from the other commands, or if your language allows it you can add runtime exceptions that are only handled by the clients that care and thrown by the commands that need to throw them.
The other extreme is that every command can fail and the client has a consistent way of handling the errors this means that the errors doesn't depend on the specific command. The client does not have to know what kind of command failed it can handle every error in the same way. Now you could have the interface of the command return an error state and the client can deal with the errors. But dealing with the errors shouldn't depend on the kind of the command for the client.
The second question is: Should a command have a state?
There are architectures where a command needs a state and some where they don't need a state.
Some possibilities to decide this:
- If you want to have a undo for your command the commands need to have a state.
If the commands are only used for hiding a way a function that works on a small set of parameters and the outcomes only depends on the same of the command like the state pattern there is no need for a state and you can use the same object over and over.
If you use the command to communicate between threads and you want to transfer data from one thread to another the command needs a state.
- ... If there is something you think should be in this list leave a comment.
У меня сейчас нет передо мной шаблонов проектирования: элементы объектно-ориентированного программного обеспечения многократного использования, но я почти уверен, что авторы даже говорят, что представленные ими шаблоны проектирования являются модель, которая может быть изменена для соответствия конкретной ситуации.
Этот вопрос затрагивает суть того, что такое шаблон проектирования - шаблон. Это не то, что нужно делать по книге. Вы определили случай, когда логическая модификация шаблона, представленного в книге, помогла бы приложению, и это прекрасно, особенно если взвесить преимущества и затраты.
Это определенно спорный вопрос, но он ясно показывает два стиля мышления:
- Проверить, в порядке ли что-то, и затем действовать соответственно
- Все равно действовать и разбираться, если что-то не так случается
Я не думаю, что один способ лучше другого. Например, в Java обычно лучше не злоупотреблять обработкой исключений и позаботиться о любых возможных проблемах, прежде чем просто бросить руки (и исключения) в воздух. С Python предпочтительнее просто продолжать и пытаться делать что угодно, независимо от кода состояния, и позволять любому исключению просто обрабатываться соответствующим образом.
Это действительно зависит от вас, хотите ли вы эту команду или нет. шаблон для возврата статуса.
В моем программном обеспечении CAD / CAM сборки, содержащие команды, ссылаются на сборки, содержащие интерфейсы и иерархию объектов, которые содержат различные элементы пользовательского интерфейса моего программного обеспечения. Это похоже на пассивное представление
Команды могут управлять пользовательским интерфейсом через интерфейсы просмотра и сами сообщать о любых ошибках.
В основном это происходит
Формы реализуют IFormInterfaces и регистрируются с помощью ScreenViews в EXE
ScreenObjects реализуют IScreenView и регистрируются в сборке ScreenView, а также команды захвата из сборок команд
Сборки команд ссылаются на сборку ScreenView и модель
Сборка ScreenView представляет собой немного больше, чем набор интерфейсов просмотра и содержит приложение Реализация.
Может быть проблема здесь в том, что команда будет выполняться каким-то классом-исполнителем, который не будет напрямую знать, что команда на самом деле делает.
Если мы говорим о добавлении возвращаемого типа Для метода выполнения существует потенциал для предоставления исполнителю типов возврата, зависящих от реализации. Под этим я подразумеваю, что вы открываете дверь в ситуацию, когда разные команды могут иметь разные наборы возвращаемых значений. Если бы исполнителю пришлось бы их обрабатывать, он стал бы более тесно связанным с реализациями команд.
Однако я часто указывал состояние команд - позволяя клиенту настраивать их с рабочими значениями при построении, а затем предоставление геттеров, позволяющих клиенту извлекать результаты выполнения команды по завершении.
Я буду ссылаться на «Шаблоны проектирования - прежде всего». Примеры, которые они используют для шаблона команд:
- сценарий закусочной (заказчик создает заказ, обслуживающий персонал вызывает его, крича обслуживающему персоналу, и персонал кухни получает заказ)
- сценарий удаленного управления ( человек нажимает кнопку, дистанционное управление вызывает команду, и устройство ее получает)
Очевидно, что в первом случае приемник создает какое-то состояние: «вот жратва» или «у нас закончился ржаной хлеб. ". В модном ресторане вы можете сделать это с помощью обработки исключений на более высоком уровне (метрдотель подходит к столу и извиняется, предлагает замену и готовит ваш десерт), а обслуживающему персоналу ничего не нужно делать, кроме как правильно вызывать команды. Но в закусочной может быть, повар идет вперед и заменяет черный хлеб - официанты (и покупатель) должны уметь справляться с этим, не глядя на прилавок, задаваясь вопросом: «А где мой тунец на ржи?» В книге это не рассматривается напрямую, но я думаю, что это вполне верный случай.
Но во втором сценарии вызывающий объект намеренно глуп. Он не выдаст вам ошибку, если что-то не так, это просто не будет иметь никакого эффекта. Все умные функции находятся в клиенте, чтобы определить, была ли его команда успешна своевременно («дерьмо, я забыл подключить его»), или в приемнике, чтобы выяснить, что делать («воспроизвести компакт-диск: закрыть лоток для компакт-дисков. first ").
Я не эксперт, но я бы сказал, что возвращение статуса вызывающей стороне вполне нормально для некоторых приложений.
Это явно допустимый случай.Но во втором сценарии инициатор намеренно глуп. Он не выдаст вам ошибку, если что-то не так, это просто не будет иметь никакого эффекта. Все умные функции находятся в клиенте, чтобы определить, была ли его команда успешной своевременно («дерьмо, я забыл подключить его»), или в приемнике, чтобы выяснить, что делать («воспроизвести компакт-диск: закрыть лоток для компакт-дисков. first ").
Я не эксперт, но я бы сказал, что возвращение статуса вызывающей стороне совершенно нормально для некоторых приложений.
Это явно допустимый случай.Но во втором сценарии инициатор намеренно глуп. Он не выдаст вам ошибку, если что-то не так, это просто не будет иметь никакого эффекта. Все умные функции находятся в клиенте, чтобы определить, была ли его команда успешна своевременно («дерьмо, я забыл подключить его»), или в приемнике, чтобы выяснить, что делать («воспроизвести компакт-диск: закрыть лоток для компакт-дисков. first ").
Я не эксперт, но я бы сказал, что возвращение статуса вызывающей стороне вполне нормально для некоторых приложений.
As said in your question:
If a command is unsuccessful, the invoking CLIENT must receive a proof of the status, and eventually deploy an appropriate reaction.
In that case, i throw runtime exceptions as status, containing necessary information about it. You could try it.
regards,
Другой компромисс состоит в том, чтобы предоставить свойство «Обработчик исключений» для конкретной команды, которая может завершиться ошибкой. Таким образом, создатель команды может обработать исключение, и вы не добавите накладные расходы на код для своего клиента. Это очень полезно, когда большинство ваших команд не должно давать сбоев.