Состояние по сравнению с поведением
Как Pedro сказал, у Вас есть проблема с отладчиком, предотвращающим насос сообщения, если Вы ступаете через код.
, Но если Вы выполняете длительную операцию на потоке UI, затем назовите Приложение. DoEvents (), который явно качает очередь сообщений и затем возвращает управление Вашему существующему методу.
Однако, если бы Вы делаете это, я рекомендовал бы при рассмотрении Вашего дизайна так, чтобы можно было выполнить обработку от потока UI так, чтобы UI остался хорошим и мгновенным.
4 ответа
Мне нравятся объекты, которые выполняют одно или другое - либо представляют что-то, что имеет поведение (в идеале, предоставляет только методы void), либо представляет чистое состояние (в идеале является неизменным и не имеет кода, кроме поддержание своего состояния и возможную проверку).
Объекты первого типа передают друг другу другой тип. Это довольно похоже на модель Актера и решает множество проблем. (если вы делаете это в Java / C #, вы можете передавать интерфейсы к первому типу как «значения».)
Я считаю, что это объекты в середине (которые являются как состоянием, так и поведением), с которыми вы сталкиваетесь с проблемами ... какое-то состояние в поведенческих объектах - это нормально, если его основная цель не запрашиваться .
Мне нравятся объекты, которые (в порядке приоритета):
- Имеют подробные инструкции по использованию их, чтобы вы не достигли недействительного состояния.
- Выбрасывать исключения, когда они находятся в неправильном состоянии, когда вы вызываете метод.
- Имейте методы, позволяющие вам утверждать, что они находятся в правильном состоянии, прежде чем вы вызываете метод.
Когда эти меры действуют , гораздо сложнее все испортить.
Объекты без поведения могут также быть хеш-таблицами, объекты без состояния также могут быть набором функций.
Поведение должно быть реализовано как отдельный класс только , если оно является универсальным и может применяться к объектам разных классов. Если это так, вы не можете выбрать «соотношение» - это зависит исключительно от количества общих стратегий в конкретной системе.
В противном случае, это случай преждевременного обобщения и, что еще хуже, необоснованного нарушения ОО-принципов. Да, это подвержено ошибкам.
Если вы проектируете объекты, которые представляют собой все поведение без состояния или все состояния и без поведения, я думаю, что где-то в вашем дизайне есть изъян. На самом деле нечасто сталкиваться с такими объектами в реальном мире, и если это не дополнительные объекты, которые вы описываете, а представления объектов реального мира, то я думаю, что это так » где-то что-то не так.
У меня нет установленного соотношения для состояния / поведения. Я думаю, что каждый объект принимает свою собственную форму, и это может значительно отличаться между объектами. Но я думаю, что со временем, и если вы много работаете над объектом, глаголы будут иметь тенденцию быть больше, чем существительные / прилагательные, то есть поведение будет доминировать над состоянием.
Это то, что я наблюдал в своих программах.